A business owner reached out to us recently because something felt off. They had hired a freelance developer to build a web app, and as the project went on, their instincts kept telling them that something about it was not right. Before taking over the code, they decided to have someone independent look at it first, and that was the right call.
Freelance marketplaces have made it easy to get software built, and plenty of freelancers do honest, careful work. This is not an argument against hiring them. It is an argument for checking what you receive before you take it over, because the handoff is the moment the risk becomes yours.
What we found
The project looked like a normal web application. Buried in one of its configuration files, after a long stretch of blank space that pushed it out of sight on a normal scroll, was a block of deliberately scrambled code.
When we worked through it, it turned out to be a loader. It decoded itself in several stages, looked up where to get its instructions from a record on a public blockchain, downloaded more code, and ran it in the background. In plain terms, it gave an outside party a way to run whatever code they wanted on any computer that opened the project.
Three details made it worse than it sounds:
- You did not have to run the app to trigger it. The code sat in a file that common developer tools read automatically, so simply working on the project in a typical code editor could set it off.
- It came and went. The project's history showed the code being added, removed and added again across versions. The client spotted that it had been restored the day before the handoff.
- The handoff itself was incomplete. The files included live passwords and keys for the database, payments, email and cloud services, sitting in plain text. There was no backup of the production database.
Hiding those instructions on a blockchain is a known technique, not a one-off. Google's threat intelligence team has documented the same technique, which they call EtherHiding, being used against software developers.
What we don't know
It would be easy to tell this story as "the freelancer was a criminal," and that is not something anyone can say from the evidence.
Who put the code there, and how it got in, is unknown. Developers are targets themselves. The same Google report describes attackers posing as recruiters and asking developers to run a "coding test" that infects their own machine, and from there an infected developer can pass the problem along to every client project they touch without knowing it. The freelancer may have been a victim before the client ever was.
It is also unknown whether any data or credentials were actually taken. What can be said is what the code made possible, which is enough to treat it seriously.
What we did
The client already knew what they wanted: keep whatever was legitimate, clean it, move it to a fresh repository and fresh hosting under their own accounts, replace every password and key, and close off every path back in from the old environment. We started by rebuilding the front end cleanly so none of the old code came along, and we are working through the rest of that plan with them.
How to protect yourself when you hire a freelancer
Most of this costs nothing, and all of it is easier to set up at the start than to untangle at the end.
- Own the accounts from day one. The code repository, hosting, domain, cloud account and payment processor should be in your company's name, with the freelancer invited in. If they set up the accounts and hand you access later, you are a guest in your own system.
- Keep the passwords and keys yourself. Payment, database and email credentials should be ones you created and can change. Sending them to the freelancer in a chat message, or receiving them back in a file, means they live in places you don't control.
- Ask for a database backup and know where it is. The code can be rebuilt. Your customer and order data cannot. Ask for a backup before the final payment and confirm you can open it.
- Change every credential at handoff. Even when everything was done honestly, the day the freelancer's work ends is the day their access should end.
- Get an independent review before you take it over. Especially if your gut is telling you something is off. A reviewer who has no stake in the original build will tell you what is there, and that includes telling you when everything looks fine.
- Have it opened somewhere safe first. If there is any doubt, the first look should happen in an isolated environment, not on the laptop where your email and bank accounts are logged in.
- Notice the small signals. Reluctance to give you repository access, a project history that is missing or rewritten, and credentials only the freelancer holds are all worth a question.
If you're already in it
Maybe the project is done and you are not sure what you have. Maybe the freelancer has gone quiet. Maybe everything works but nobody can tell you how. You are not stuck, and you don't have to start over to find out where you stand.
This is a large part of what we do. We review code someone else wrote, tell you plainly what we find, and if you want, we take it over and keep it running. Sometimes the answer is that the work is solid and you just need the keys in your name. Sometimes it is more. Either way you will know. More on that is on our project takeover page, and if the app was built with AI tools, our vibe code cleanup page covers that case.
If something about a project you hired out doesn't sit right, tell us about it or call (507) 388-4748. Better to look and hear that it's fine than to find out the hard way.