We were hired to rework a website, found backdoors nobody had asked us to look for, and blocked the requests a customer reported the same night.
A small business hired kratt to rework its website. While preparing that work we found backdoors in the site’s files, first in a copy on our own machine and then in a read-only look at the server. We told the business the same day and moved the files out of public reach once it agreed. Weeks later a customer reported another hole. We verified it, blocked the reported requests that same night and widened the block the next morning. The logs we kept cover only part of the period, so we cannot say whether anyone used that hole before then.
- 3 filesmoved out of public reach the same day the business said yes. We deleted none of them.Build receipt
- Same dayfrom finding the backdoors to telling the business.Build receipt
- Same nightthe requests a customer reported were blocked. A wider block followed the next morning.Build receipt
- 1 live testof the form customers use, on the live site after the block was widened. It went through from start to finish.Build receipt
How these were measured: These figures come from our own work records. The file move and the first message come from the notes we wrote at the time and the messages we sent the business. The report time comes from the header of the customer’s email, the block from the before and after checks recorded that night, and the live test from the record made the same morning.
Evidence class: Client delivery
Reviewed 2026-11-05 · Kratt editorial review
A rework on a live site, with customer records behind it.
The site was live, with real customers and their records behind it, and the job was a rework. Security was one small line in the order, and looking for backdoors was not in it. To prepare the work we downloaded a copy of the live site and started on it on our own machine.
- We work on the site as the business’s data processor under a written agreement. The business is the data controller.
The copy held a backdoor and a file that deleted other files.
One file in that copy was a backdoor, a file manager that could read and change any file on the site and run code. That reach extended to the database and the customer records in it. A second file deleted files as soon as anyone opened it, with no login. Code like that is not safe to run, so we read it on our own machine, with no network connection. No request went to the live site during that reading, and we changed nothing on it. A read-only look at the server then showed both files on the live site, and a slightly different copy of the backdoor in another folder. We read that one where it sat and did not run it either.
We told the business the same day and moved nothing until it agreed.
The business is the data controller, so it had to hear this from us quickly, and nothing would move without its yes. We sent it a plain message the same day: what the file could do, what the logs showed, what we proposed and which passwords it would need to change itself. We also said that if older logs showed the backdoor had been used, the business might have to notify the data protection authority within 72 hours. The business agreed, and later that day the three files were out of public reach. We kept the evidence and a script that puts them back.
The files had to go before the passwords.
A backdoor that can read any file can read a new password too, so we changed credentials only after the files were out. We replaced the site’s secret keys, and then changed the database password and the file-transfer password. An old administrator account lost its rights, and we kept the account. The business reset its own site password from a link we sent, because passwords do not travel through chat.
- We compared the site’s core files and its free components in our copy against their official checksums, and they matched. The paid components have no public checksums, so we had nothing to check them against.
- We went through access and scheduled work in the hosting account.
- We searched the rest of the account for anything set up to survive once the files were gone. It raised two flags, and we traced both to false alarms.
- The hosting provider ran its own malware scan at our request. Its reply named the two backdoor files and said it saw no unfamiliar accounts.
- The logs we could read do not cover the whole period, so they could not show whether the backdoor had been used earlier.
A customer reported another hole, and that night we blocked the requests.
Weeks later, in the evening, a customer emailed us and the business. The customer said a part of the live site answered requests without a login and could reach customer records. We checked that night. The part that answered without a login we confirmed on the live site, and its reach into customer records we confirmed in the code. It belonged to an old add-on that no longer received updates, already on our risk list, with the swap to a supported version waiting on a decision on cost. The hole put contact and other customer details from thousands of records within reach. This describes what could be reached. It is not a count of what anyone took, and we cannot state it as an upper limit. The block had to refuse those requests and leave the form customers use alone. That same night a small block we wrote was refusing them. We compared the responses before and after: the reported requests were refused, and the form still loaded and answered.
The next morning we went looking for what the customer had not reported.
The first block refused the requests the customer had reported and a few closely related ones, and that was not everything. The next morning we reviewed the site more widely, looking at it as a visitor with no login would. We worked largely by reading the code and did not try every finding on the site. That morning we widened the block and tightened several other settings. A wider block could have refused real customers too, so we tested the site the way a customer uses it. One of us went through the form on the live site from start to finish, and it worked. A real customer’s request went through the same morning. About two days after the report, a current version of the add-on that can receive updates replaced the old copy. Old access links stopped working.
What the logs show, and where they stop.
Logs are what can show who used a hole. That same night we copied the logs the server held and took checksums, and the next morning we copied them again. The copies cover only part of the period. In the days they cover, the only anonymous uses of the part the customer reported are the customer’s own test and our own checks. We saw no mass download and no run through record numbers. A short request came from an address we could not identify. It reached a related part of the site and falls outside that count. We have no sign that it returned customer records. A check of the database showed no sign that records had been changed or removed. That check cannot show more than that. We asked the hosting provider for older logs and have no answer on file. So we cannot say whether anyone used the hole before then.
On a site we take over, this check now comes first.
A site we take over can hold things nobody has told us about. So the first job on such a site is now a security check, before the planned work starts. We keep it as a written procedure. It starts from an offline copy, tells the business before anything changes, moves suspect files instead of deleting them and changes credentials in a fixed order. It also looks for anything set up to survive.
What we left alone
Two choices we made on purpose.
- The moved files. We kept them as evidence rather than deleting them, even after the host said they could go.
- The decision on notifying the data protection authority and customers. It belongs to the business as data controller, and this page does not report it.
Ownership and handover
Current owner
The business is the data controller. The hosting account is the business’s.
Kratt's role
kratt works on the site as the business’s data processor under a written agreement.
Handover
Nothing has to move. The hosting account stays with the business.
What this page does not claim
- That the site is secure now, or that everything we found was closed. This page says what we changed and what we checked at the time.
- That we found the second hole first. A customer reported it.
- That no data was copied, or that nobody used the backdoors or the hole. The logs cover only part of the period, so we cannot say.
- That the first block covered everything. It did not, and the wider block followed the next morning.
- That we know every way in. We cannot say what else could be reached before the report, or whether anyone used it.
- Who planted the backdoors. We do not know.
- That every file on the site was proven clean. We could not prove that, and the paid components have no public checksums to compare against.
- That this was a penetration test or an independent audit. It was our own work on a site we were working on, and apart from the hosting provider’s own malware scan, nobody outside checked it.
- That kratt is a security firm. We do not sell this as a service.
- Any effect on revenue or customer trust. We did not measure one.
- Any response time, price or term of ours. The times on this page describe one job.
- Everything that happened on the site. This page covers two stages of the work and is not a full record of either.
What an owner asks about this work.
Was customer data taken?
We do not know. The logs we kept cover only part of the period, so we cannot say whether anyone used the hole before then, and they cannot show that no data was copied.
What does the first check on a site we take over cover?
It starts from an offline copy of the site. We tell the business before anything changes, move suspect files instead of deleting them and change credentials in a fixed order. We also look for anything set up to survive.
Does kratt sell security work?
No, we do not offer it as a service. We did this work because we were working on the site under a written agreement when these problems came up. kratt’s free audit looks at how a company’s workflows run, and it is not a security test.
How we check that our own backups restore:the weekly restore test
Karl-Kristjan SaarCEO · Co-founder · runs the audit call
Do you know what is in your website’s files?
If someone else built your site, or a rework is coming, we spend 30 minutes with you on who has had access and what you want changed. You leave knowing what we would check first. The call itself is not a security check.
Book a call about your websiteBack to all case studies.