The Go build records an Overlord module path

The Linux amd64 artifact is 15,790,242 bytes and has this SHA-256:

ef183bbb40f4c7c3f4b52994cdba3295f3eab2604fdad99eefa3b67b8d966e8d

I read these fields from its Go build information:

path                 overlord-client/cmd/agent
module               overlord-client (devel)
wazero               v1.7.0
modernc.org/sqlite    v1.34.5
CGO_ENABLED          0
GOARCH               amd64
GOOS                 linux
vcs.revision         056221e342357056c8539585806f76632660e414
vcs.time             2026-07-21T01:14:06Z

The module path connects the binary to the Overlord agent codebase, the wazero dependency supplies a WebAssembly runtime (consistent with the framework's plugin support), and SQLite provides local database functionality, which becomes relevant alongside the browser-store markers elsewhere in the file.

The Go build-setting documentation defines vcs.revision as the checkout revision and vcs.time as its associated modification time. The timestamp is version-control metadata. The binary's compilation time remains unverified. The recorded repository lookup did not locate the embedded revision, leaving the corresponding source checkout unresolved.

Figure 1. The agent combines Overlord framework markers with browser, wallet and capture-related components.

The upstream files shared generic framework features

The July comparison inspected selected client module and configuration files; it found the shared module path, plugin support and generic transport configuration, and it also recorded a newer wazero version in the examined upstream module file than the sample's v1.7.0. The dependency versions differ. Dating the fork or deployment requires additional records.

SQLite-related dependencies and wallet/browser markers were absent from the selected upstream files, and those files were not retained at a pinned revision, preventing a reproducible source diff; other versions, forks and plugins were not exhaustively compared. The authorship of these components remains unresolved.

Browser stores, wallet selectors, and capture symbols

String examinations found Login Data, Local State, logins.json and key4.db, along with wallet names and extension identifiers. These are browser-store and collection selectors. Together with SQLite, these selectors identify what the agent is built to read, but successful access and decryption on a victim host remain unmeasured.

The wallet-related markers include an endpoint setting, a client header and an upload path, and the companion's wallet-agent YARA rule combines these with the Overlord module and server-environment markers. A generic framework match would also identify unrelated Overlord deployments. Requiring wallet context narrows the search to files carrying that additional combination.

The binary also contains previous-frame, block-comparison and capture-loop symbols, which provide evidence of capture-related implementation despite the absence of expected packages in the selected upstream dependency files. The capture analysis examines those symbols and the separate Windows bundle. Display access, code reachability and successful transmission were not reproduced.

The phased JavaScript collection, GUS-prefixed configuration and Windows Node/Python pipeline occur in separate components of the toolchain, and their functions extend the collection paths beyond the Go executable, yet they cannot all be assigned to changes in one agent's source.

For file hunting, the wallet-agent rule and capture-agent rule select different marker combinations. Both remain experimental. A hit identifies content for inspection, and can include source or research material containing those strings. For an unexpected installed agent, preserve its hash, configuration, launch mechanism and outbound destinations alongside the matching offsets.

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

The wallet-agent rule initially matched marker-rich research prose, and requiring ELF magic at byte zero rejects that text fixture. It checks the header, not the executable's behavior.

The companion repository contains file-content rules and a parse-only JavaScript scanner, but it no longer includes the event rules or workspace-configuration rules: authentic endpoint logs and the original .vscode task and settings files were not available for replay. Synthetic event records and invented configuration files would show how a rule behaves, not whether it matches the collected targets.

The wallet-agent rule matched the held Go binary

The wallet-agent rule now requires ELF magic at byte zero, a file smaller than 64 MiB, an Overlord module path, a server-environment marker and at least two wallet-collection strings. The combination matched the held Go agent. Removing the header or one required marker category gives a negative result in the inert boundary tests.

The earlier rule version matched a harmless fixture with the complete marker set in research prose, and requiring the ELF header at offset zero prevents that ordinary text collision. YARA does not validate the rest of the executable or determine whether the strings are reachable code. So a marker-rich ELF can still match.

A file signature identifies matching content. Execution and data transfer require host evidence; operator attribution requires a separate investigation.

Figure 1. Every wallet-agent condition is required. The retained rules matched case artifacts, while the local software baseline and marker-rich prose fixture had no hits.

The replay covered 192 files and 395 views

The read-only replay covered 192 selected files: the 15 directories marked DO-NOT-RUN, compressed lure bundles, web assets, extracted VSIX components and agent archives, source files, and six retained lure messages, and the helper read ZIP, VSIX, TAR, gzip and nested ZIP content in memory without writing extracted files.

It evaluated 395 raw or archive-member views totaling about 234 MB, and all 33 named rules in 28 files matched at least once (at least one rule matched 90 input files, and 102 had no hits). The totals include copied variants and nested archive views, so they are not independent samples or incidents; Exhibit E15 records the companion snapshot and validation scope. No file was executed.

Four ECHOES RAR archives require a password, so their members were not inspected, while the separate sealed-environment archive was scanned only as raw bytes, and exact hashes identify the four ECHOES containers without making claims about their contents.

A separate exact-hash rule identifies the retained Surge Group message. It does not claim the message shares control with UNK_DeadDrop. Other hash rules identify exact retained packages, launchers and messages. Modification or repackaging evades them.

Most unmatched inputs were generic dashboard modules, web assets or research context without a distinctive file-content signature; they were included in the coverage accounting, but weak rules that only identify those records would not be useful detections.

Workspace-file signatures remain absent because neither the original .vscode/tasks.json nor .vscode/settings.json appears in the saved repository archive or its commit history, and event rules were removed because there are no authentic Windows process, Linux audit or comparable endpoint logs in the retained set. The companion therefore has no Sigma rules. The two SQLite databases containing target addresses were also excluded from scanning.

The companion's artifact-validation report lists per-rule match counts and corpus limits. Its detection notes explain each condition and its limits.

No matches in 1,914 local software files

The second scan covered 1,914 files and about 59.2 MB across 2,379 raw and nested object views from the local CPython standard library, installed Python packages, global npm packages and Acorn. No retained rule matched. The 19 Markdown articles and companion notes also produced no hits after source-oriented conditions were narrowed to avoid prose collisions. The baseline consists of local software. Its small, uncurated sample cannot support estimates of fleet false-positive rate or production precision.

The prose fixture remains important alongside that zero-hit result, as it records a false-positive case from the rule's earlier form and confirms the current ELF-header check rejects plain text; analysts should still review file type, acquisition context and matched bytes before treating a hit as suspicious. For process and persistence behavior, collect authentic endpoint logs first; this repository does not publish event rules without them.

A later local review covered 177 case inputs, 380 views and 344 distinct objects, and seven source rules were narrowed after collisions in selected research, dual-use tooling, ordinary software, installed software and upstream-fork controls. Every previous case-artifact match was preserved. The seven revised forms had no hits in the external controls scanned, but this bounded control set does not estimate a production false-positive rate; the revisions remain separate from the public companion snapshot.

YARA matches byte patterns; unk-scanner parses JavaScript

The YARA replay measures whether particular bytes match the signatures, while unk-scanner instead parses JavaScript and follows selected expressions, string decoders and launch structures; a file can match a content signature while the scanner misses its behaviour, or produce a scanner warning because it uses obfuscation that also appears in legitimate software.

The expanded scanner evaluation now has its own paper, which covers popular npm packages and editor extensions, recently changed npm packages, and a separate public malware dataset. The final popular-software scan raised no errors in 188,901 files outside the initial calibration corpus, although an earlier run on those files informed one escalation-rule adjustment, and in the registry changes corpus, two of 19,976 packages raised errors; full review classified both as false positives.

Sensitivity tells a different story. Only 62 of 2,122 known-malicious samples raised warnings, with none reaching error level, and most lacked the clipboard, Electron or encrypted-loader structures that the higher-severity rules recognise; the retained Windows Node agent also stays below warning level, yet its known collection functionality does not become benign because this rule set misses it.

Part 13 covers corpus selection, review depth, parser coverage and throughput. Part 14 examines nineteen small variants, eighteen of which evaded a rule, lowered severity or defeated string recovery, and a hardened engine that later closed all but one of them without adding error-level findings on the same corpora. These results concern the scanner, not the 33 YARA rules or their earlier control set.

Rule matches depend on the bytes given to YARA

YARA can inspect only the bytes supplied to it. A rule for decrypted JavaScript needs those plaintext bytes, a rule for a VSIX member needs the member supplied to the engine, and scanning an outer compressed package alone is not equivalent to the archive-member replay above. Consult each rule's target and match conditions before choosing a sample.

A hunting service may use a different rule set for manual file scans. Check where the uploaded rules are deployed.

The repository includes inert YARA boundary tests, a prose false-positive test, and the test requirements. Run the checks using the instructions in its README. These tests are repeatable checks of rule behavior, not malware execution or production validation.

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

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

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:

1. 26 May 2026, final listed revision of config.json: api.domatisc[.]ink and api.coslyintra[.]online.
2. 1 June 2026, separate file config-alt.json: api.onoplainai[.]ink and api.migadyn[.]info. Its use by the recovered client is unestablished.
3. 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

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 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":

1. Clone the repository.
2. Open it in Cursor and analyze it with AI.
3. Write a few prompts.
4. 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