Contagious Interview 2.0: Weaponizing Dev Tools & Fake Recruiters
Just caught the latest Proofpoint report regarding the Contagious Interview cluster (HexagonalRodent/Void Dokkaebi). They are pivoting from simple fake interviews to actively compromising developer workflows. The campaign uses phishing lures themed around code reviews or developer recruitment, but the real kicker is how they are weaponizing developer tools to deliver the payload.
They appear to be leveraging compromised build chains or malicious extensions that look legitimate. Once the "interview" code is executed, it establishes a C2 channel. Since this targets developers with local admin rights on their boxes, the fallout is immediate.
I've tuned a basic Sigma rule to catch the behavior where common IDEs or Node processes spawn suspicious shells, which is a strong indicator of these malicious post-exploitation scripts:
title: Potential Malicious Dev Tool Execution
status: experimental
description: Detects shells spawned by common IDEs or Node.js processes
logsource:
category: process_creation
product: windows
detection:
selection:
ParentImage|endswith:
- '\Code.exe'
- '\node.exe'
Image|endswith:
- '\powershell.exe'
- '\cmd.exe'
CommandLine|contains:
- 'DownloadString'
- 'iex'
condition: selection
falsepositives:
- Legitimate build scripts
level: medium
Has anyone else encountered these lures recently? How are you handling the tension between developer freedom (installing random VS Code extensions) and supply chain security?
Good catch on the Sigma rule. We noticed a similar pattern last month where the payloads were obfuscated Python scripts inside zip files labeled 'source_code_review'. We started blocking .zip attachments from non-corporate domains, but if they are moving to direct repo cloning or extension installs, we need to rethink our egress filtering. I'm considering setting up an air-gapped analysis VM for any external code reviews our team participates in.
This is exactly why we enforce allow-listing for VS Code extensions via GPO. It's a bit draconian and the devs complain, but it stops the 'oops I installed a cool looking theme that turned out to be malware' vector. If they can't verify the hash of the extension against our internal list, they can't install it. The Contagious Interview group is persistent; if you give them an inch with local admin rights, they'll own the domain.
From a pentester perspective, this is a perfect social engineering attack. Who doesn't want a high-paying remote dev job? I've been recommending clients monitor for anomalies in npm or pip package installs during 'working hours' that aren't associated with active projects. You can use this simple Python snippet to audit recently installed packages against known malicious timestamps:
import pkg_resources
import time
treshold = time.time() - 86400 # Last 24 hours
for dist in pkg_resources.working_set:
# Requires access to package metadata files
pass
Keep in mind, verifying the publisher integrity is just as important as the code itself.
On the Red Team side, we’ve been testing detection logic for pre-commit hook abuse. It’s a sweet spot because it executes in the user context but touches the repo. You can catch some of this activity by auditing .git/hooks/ or monitoring for child processes spawned by git. Here is a basic PowerShell check to run on endpoints to look for non-standard hooks:
Get-ChildItem -Path (Get-ChildItem -Recurse -Filter .git -Hidden -Directory -ErrorAction SilentlyContinue).FullName -Filter "pre-commit" -File | Where-Object {$_.Length -gt 0} | Select-Object FullName, LastWriteTime
It's noisy, but finding obfuscated scripts in those folders is a huge red flag.
Another vector to watch is process injection via the IDE terminal. Since these lures often ask you to run a 'setup script,' monitoring for rare parent-child process relationships is key. Here is a KQL query to detect shells spawning directly from VS Code or JetBrains IDEs:
ProcessCreateEvents
| where InitiatingProcessFileName in~ ("code.exe", "idea64.exe", "devenv.exe")
| where FileName in~ ("powershell.exe", "cmd.exe", "bash")
This helps spot payloads executing immediately after cloning a repo.
Don't overlook malicious Git configurations. Threat actors are abusing core.sshCommand within .git/config to hijack SSH traffic whenever the user clones or pushes. This bypasses standard hook detection since it’s a config directive, not a file.
You can hunt for this anomaly with a quick check:
git config --global --get-regexp sshCommand
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access