Executive Summary

An operator has spent the summer of 2026 publishing malicious packages to the public npm registry under names that belong to somebody else. Not names resembling popular libraries, which is the usual pattern, but the internal package names of one company. We track the activity as TXTBOOK. It began on PyPI, moved into npm with its execution trigger rebuilt for the new ecosystem, and now runs to 993 npm packages.

CloudSEK's supply chain monitoring surfaced them and from those packages we pivoted to the rest: the staging infrastructure, the command and control estate, the third stage implant, and finally the target.

What matters is who the 993 packages are named after. They reproduce the internal, private package namespace of a single organisation: Tinkoff, the Russian financial group now trading as T-Bank. The names cover the group's BNPL product, its business banking platform, its analytics client libraries, and the proprietary counterparts of its own published open source projects. This is a dependency confusion operation aimed at one company, run at a scale normally associated with indiscriminate registry flooding.

The targeting is not inferred from names alone. The second stage loader carries a hardcoded, obfuscated table of hostnames, and three of its nine entries are victim infrastructure rather than attacker infrastructure. All three belong to the T-Bank group. Before contacting its own command and control servers, the loader resolves the group's internal artifact repository and proceeds only if it answers. This ensures that the malware has been run inside the bank’s internal network. The malware carries its own definition of the target.

A small secondary cluster of online betting names is present in the same advisory data. It is four packages out of 993, none of which were held in our corpus, and it is reported here as an observation rather than a co-equal target.

TXTBOOK's delivery technique remains its most distinctive feature. Rather than downloading a binary over HTTP, the loader reassembles a native executable from several hundred DNS TXT records, a few hundred bytes per record. To a network monitor the activity is a burst of DNS lookups. The third stage that arrives by this route is a Sliver implant with an effectively complete command set, and its command and control protocol has now been reversed from captured traffic, recovered key material and static analysis of the binary.

Key Findings

• The campaign comprises 993 packages, and the naming is a private namespace reconstruction of one organisation. Strict prefix matching attributes 850 of 993 to T-Bank; the remainder are generic banking-platform names (claims, deposits, cards, certificates, business process management) that are consistent with the same source. Seven names, under one percent, point anywhere else.
• The loader carries a hardcoded target gate. Its obfuscated hostname table decodes to nine entries on Windows, macOS and Linux ARM64 alike, of which three are victim infrastructure: the group's Nexus artifact repository, its Linux package repository, and the alerting endpoint of CloudPayments, a payment processor T-Bank has wholly owned since 2023. The malware defines its own target.
• The squat list leaks an internal service catalogue. Package names of the form statist-browser-typed-client-* embed internal service paths such as mb.product.payments, sme.rko.conversionpayments.web, investaccounting.events, leasing.admin.events and dwh.chimera.base. These are not guessable strings; they indicate the operator worked from a real inventory of the target's internal systems.
• The operator squats the proprietary siblings of the target's public open source. T-Bank publishes the Tramvai application framework and the Taiga UI design system openly; the campaign registers tramvai-* and taiga-ui-proprietary-* names. Public repositories give an attacker an accurate, free guess at private package names.
• A previously undocumented version band is the largest we hold. Published versions were understood to fall into four generations. A 20.x band accounts for 199 of 331 verified archives, more than the 33.x, 34.x and 35.x bands combined, and reassembles the same command and control batch, so it belongs to the same infrastructure era.
• The third stage is a Sliver implant, and its protocol is now fully understood. The implant encrypts with age rather than Sliver's native scheme, authenticates its server with an Ed25519 minisign signature on every response, and selects one of five traffic encoders per request. Beacon traffic was decrypted in the analysis environment by substituting a controlled key into the running process, which yielded the plaintext of the command and control exchange.
• The campaign runs two separate operator servers. Two independent cryptographic identities, an age recipient key and a minisign signing key, partition the platform builds identically: Windows and Linux ARM64 to one server, Linux x64 to another. Both are fronted by the same Cloudflare Workers estate, so shared front end infrastructure does not imply a shared back end.
• Obfuscation was applied inconsistently. The Windows and macOS builds have their string literals encrypted; neither Linux build does. The Linux implants carry the operator's keys, their own private keys and their command and control hostname in plaintext on disk, which makes captured server to implant traffic for those builds decryptable with no runtime analysis at all.

Required Actions

• Treat this as a targeted campaign against a named organisation, not as registry flooding. If you operate any part of the T-Bank estate, or build software that resolves dependencies inside it, assume the private namespace is known to the operator and enumerate which of the 993 names exist internally.
• Configure registry scoping so private package names cannot resolve to the public registry. Dependency confusion is defeated by resolution policy, not by blocklists; the 993 names in Appendix A are the symptom.
• Block the DNS staging zones and the Cloudflare Workers command and control estate listed under Indicators of Compromise, and hunt DNS telemetry for sequentially numbered TXT lookups that reassemble into an executable.
• Pivot on the operator's minisign server keys rather than on hostnames. A minisign key identifies a Sliver server installation and survives infrastructure rotation, campaign renaming and rebuilds.
• Treat the presence of any listed package in a lockfile as a compromise and rotate every credential available to the affected build environment.

Analysis

How the Campaign Unfolded

The operation did not begin with npm. It was first documented on PyPI in July 2026, as the campaign tracked 2026-07-andreiiiiiii_i and, before that, as activity around a configuration client package. The move into npm reused the infrastructure wholesale: the same staging domains, the same command and control estate, the same third stage. What changed was the execution trigger, which was rebuilt for the new ecosystem. On PyPI the operator installs a path-configuration file that the interpreter runs at startup. On npm it appends a required call to the package entry point, which runs on import. Both achieve code execution without declaring an install hook. That is a deliberate port, not a reused payload.

Publishing proceeded in waves rather than continuously, and the version numbers separate them cleanly. Each wave changed the thing that had made the previous one detectable. The earliest packages avoided npm lifecycle scripts altogether. A later wave reintroduced a postinstall hook. The most recent returned to import-time execution and added per-package payload variation, so that no two packages share a hash and the loader filename differs in every one.

The supporting infrastructure was provisioned in batches ahead of the packages that would use it. The command and control estate spans roughly two dozen Cloudflare accounts in two clearly separate naming batches, and a second staging domain was registered, shipped inside live packages, and left dormant, resolving but serving nothing. The operator was building the next stage of the campaign while the current one was still running.

Registry enforcement has not displaced them. When npm removed nine of the first ten names on 1 August 2026, publishing resumed within roughly a day, and by 3 August three of those names carried live malicious versions again. The publishing accounts explain why: they are disposable, and almost every one holds a single package, so removing an account removes a package rather than an operator.

CloudSEK's supply chain monitoring surfaced the first ten packages of the npm arm, and those names are what made the rest reachable. Everything that follows, the staging channel, the native loader, the implant and the target, was recovered by following them.

Tradecraft Evolution

Published version numbers cluster into distinct bands, and the bands correspond to changes in execution technique. The earliest avoid npm lifecycle scripts entirely, triggering from a single line appended to the package entry point so that importing the module suffices. A later band reintroduces a postinstall hook. The most recent returns to import-time execution and adds per-package payload variation, defeating hash-based clustering.

The 20.x band is a correction to the previously published four-generation model. It is the largest single band in our holdings and reassembles the same command and control account batch as the 33.x to 35.x bands, so it belongs to the same infrastructure era rather than to an earlier one. Any taxonomy of this campaign built on the four generations alone is incomplete.

Malware Analysis

Following the packages meant following the payload, and the payload did not cooperate. Each step below depended on the one before it, so the order is the order of work. The chain has four stages: an npm package that executes on import, a loader that retrieves its payload over DNS, a native second stage, and a Sliver implant. Recovering the fourth stage required building a purpose-made detonation environment, reading keys out of the running process, and modifying that process in memory while it ran.

Building the Analysis Environment

The sample refuses to run in commercial sandboxes, so a bespoke environment was built. A Windows 10 guest runs under a QEMU/KVM hypervisor on an isolated virtual bridge with no uplink. A local service answers every DNS query and accepts every TCP connection, minting per-name TLS certificates from a certificate authority already trusted in the guest's machine store, so the implant's HTTPS beacons complete a handshake and expose their payloads at the capture layer. Packet capture happens on the host, outside the guest's reach.

Detonation, and a Loader That Cannot Run Its Own Payload

The first detonation produced no beacon. A memory capture taken during execution explained why: the third stage payload was resident in memory still compressed, its packer section names intact and no runtime initialised. The loader maps its payload reflectively, allocating memory and parsing the executable header by hand, but it performs no decompression, and the Windows third stage is packed.

This is the most likely explanation for the sparse public behavioural record on this family. The third stage must be executed directly to be observed at all.

Recovering the Loader's Configuration

The loader stores its hostname table obfuscated rather than as plaintext strings, using a single-byte XOR key that differs per build. Recovery needs nothing more sophisticated than trying all 256 keys and scoring each result by how many well formed hostnames appear, without reference to any previously recorded key. Nine hostnames emerged. Six are the operator's own infrastructure. The other three are not, and they are what the rest of this report turns on.

Identifying the Third Stage

The implant is a statically linked Go binary with no import table beyond the bare runtime, no package paths and no program strings, because it was compiled with an obfuscator. Conventional string-based capability profiling returns nothing. What survives is Go's reflection metadata, which the runtime requires in order to marshal messages and which therefore cannot be stripped.

Probing that metadata for the framework's command-message type names recovered 79 of 82. The three absent names are spelling variants, not missing capabilities, so the implant carries an effectively complete command set.

Why the Keys Are Not on Disk

This was confirmed exhaustively rather than assumed. The operator key, the implant keys, the protocol identifiers and even the command and control hostname are all absent from the unpacked binary under single-byte XOR, additive and subtractive constants, position-dependent XOR, and repeating-key XOR up to period eight. A full pairwise search, testing every offset in the file against an index of every eight-byte window for the relation ciphertext XOR key equals plaintext, also returned nothing.

Reading the Keys Out of Live Memory

If the secrets exist only at runtime, the runtime is where they must be read. The guest's entire physical memory is a single mapping inside the hypervisor process on the host, and guest physical addresses are a fixed offset within it, so the host can read guest memory directly while the guest runs.

Scanning the guest's memory for the format's key encoding recovered both the operator's public key and the implant's own key pair. Note that a search for conventional padded base64 finds nothing here, because the format uses unpadded encoding, which is why the keys had not surfaced earlier.

Substituting a Key in the Running Process

Two representations of the operator key exist in memory: the human-readable encoded string that the implant parses, and the raw decoded bytes derived from it. Only the encoded string is authoritative. The decoded bytes are a by-product regenerated on every use, so overwriting them achieves nothing durable, which cost considerable time to establish. Overwriting the single encoded string, with the guest paused and the target verified before and after the write, causes every subsequent beacon to be sealed to a key we hold.

The Decrypted Beacon

With beacons sealed to a controlled key, the plaintext of the command and control exchange becomes readable. Each beacon carries a freshly generated symmetric session key wrapped in the framework's session-initialisation message. Every beacon carried a new one, which established that no session was ever completed during analysis: the implant was repeatedly restarting a handshake that the isolated environment never answered.

The Transport Layer

Before encryption is even reached, each message is wrapped in one of five interchangeable transport encoders, chosen at random per request. The choice is communicated to the server in a single-letter query parameter whose value is a numeric nonce; the encoder identifier is that nonce modulo 65537. Random letters are spliced into the decimal value before transmission, so the digits must be extracted before the modulus is taken.

The image encoder is not simple pixel packing. Payload bytes are written down columns rather than along rows, and the values zero and one are escape-encoded before packing, because a raw zero byte would be lost to the image encoder's padding. A decoder that reads rows in the obvious order recovers only the first thirty bytes and appears to have found a truncated message.

How the Server Authenticates Itself

The verification keys were recovered from the same memory image, and they are the most durable indicator in this report. A signing key is generated once per server installation and signs every implant that server builds, so it identifies the operator's infrastructure independently of any hostname.

Locating the Cryptography Without Symbols

Function names are destroyed by the obfuscator, so the cryptographic routines were located structurally instead. Two properties survive obfuscation: the constants a cipher must use, and the arithmetic a construction must perform. The authenticated-encryption routines are identifiable from length arithmetic alone, because sealing appends a sixteen-byte authentication tag and opening removes one.

Measuring the proportion of indirect calls established that only names and strings are obfuscated, and that control flow is intact: 0.2 percent in the cryptographic routines and 2.09 percent across a sample of the code section, consistent with ordinary compiled Go rather than with flattened control flow, which would show fifteen to forty percent.

Two Operator Servers

Extracting the signing key from each platform build partitions the campaign, and the encryption keys partition it identically. Two independent cryptographic identities agreeing on the same split is strong evidence of two distinct server installations.

Obfuscation was applied inconsistently across the four builds, and the inconsistency is itself useful. String-literal encryption was applied to the Windows and macOS builds but to neither Linux build. The Linux implants therefore carry the operator's keys, their own private keys and their command and control hostname in plaintext on disk. Captured server to implant traffic for those builds is decryptable offline with no runtime analysis whatsoever, and the macOS build is the only one whose server cannot be attributed by this method.

Who Is Being Targeted

Recovering the loader's configuration in the previous section produced something the package names alone could not: a list of hostnames the malware carries but does not own. Three of them belong to the victim. That is where the campaign stops looking like registry spam and starts looking like an operation with an address.

The 993 package names are the primary evidence, and they are unusually legible. A conventional typosquat imitates something popular: a character transposition of a widely installed library, or a plausible-sounding utility. These names do neither. They are internally structured, product-specific and organisationally coherent, in the way that a company's private package registry is coherent.

The malware names its own target

Name analysis establishes intent but not much more, so the second line of evidence matters more. The second stage loader stores its hostnames as an obfuscated table rather than as plaintext strings. Recovering the table by exhaustive key search, rather than by reusing a previously recorded key, yields the same nine entries from the Windows, macOS and Linux ARM64 builds. Six are attacker infrastructure. Three are not.

All three victim entries belong to one corporate group. CloudPayments is a Russian payment processor that T-Bank acquired in stages, taking a 55 percent holding in October 2017, 95 percent by August 2019 and full ownership in January 2023. It reads as an unrelated third party only if the ownership is not known.

The gate is also behavioural, not merely declarative. Across three independent detonations, nexus.tcsbank.ru was the first DNS query the sample issued, resolved twice, before any command and control host was contacted. The loader proceeds down the list only until one entry answers, which is why the second and third victim hostnames appear in traffic only when the first is unavailable. The malware is asking whether it has landed inside the target network.

An internal service catalogue in the package names

The analytics client family is the most revealing part of the squat list. These packages follow a rigid convention in which the trailing segment is an internal service path, and the paths are far too specific to be invented.

A name such as beaver-ui-drawer could be guessed. A path such as sme.rko.conversionpayments.web could not. The operator worked from a real inventory of the target's internal systems, obtained before the packages were published. How that inventory was obtained is not established by this analysis, but the plausible sources are narrow: a leaked lockfile or build manifest, an exposed internal registry index, a public code-search hit on a private configuration file, or a former insider.

Squatting the proprietary siblings of published open source

T-Bank maintains a visible open source presence, including the Tramvai application framework and the Taiga UI design system. The campaign registers names in both lineages, among them tramvai-module-feature-toggle, tramvai-tinkoff-module-legacy-popup and taiga-ui-proprietary-navigation. The last is the most instructive: the public design system is Taiga UI, and the name asserts the existence of a proprietary counterpart.

This is a low-cost, high-yield reconnaissance route that generalises well beyond this victim. An organisation's public repositories reveal its internal naming conventions, its module boundaries and often the names of private packages referenced in configuration. Any company publishing open source under a corporate identity should assume the private namespace adjacent to it is inferable.

How Far the Campaign Reaches

Knowing who the operator was aiming at changes the question from what the ten packages were to how many more of them exist. The answer came from sweeping the package corpus for the loader's structure rather than for any name or hostname.

The expansion happened in three steps, and the provenance of each matters when weighing the total.

The final step swept all 190,045 npm archives held in CloudSEK's package corpus for the loader's structural signature. Because the loader assembles its hostnames from string fragments at runtime, a search for whole hostnames finds nothing; the sweep therefore keyed on fragment-safe substrings combined with the campaign's characteristic file layout. Every archive that matched was then opened and confirmed by reassembling the fragments back into command and control hostnames, which is the part that cannot occur by coincidence.

Cada um dos 187 novos pacotes foi verificado individualmente, e não em conjunto. Todos eles geram pelo menos um nome de host de campanha quando os literais de string fragmentados em seu carregador são remontados, e nenhum foi aceito apenas com base no layout do arquivo. O nome do arquivo do carregador é aleatório por pacote em pelo menos quinze formas neste conjunto, entre elas _adapter.js, _bridge.js, _init.js, _compat.js, _platform.js, _runtime.js e setup.js, portanto, heurísticas baseadas em nomes de arquivo não os agrupam.

O número resultante é um piso, não um censo. Ele conta apenas o que nosso corpus já continha, e os nomes dos clientes de análise são tão formulaicos que é muito provável que o conjunto publicado pelo operador seja ainda maior.

Indicadores de Comprometimento

Chaves de Assinatura do Servidor do Operador

Estes são os pivôs de maior valor neste relatório. Uma chave minisign identifica uma instalação de servidor Sliver, não uma campanha, e, portanto, agrupa amostras em toda a rotação de infraestrutura, renomeação e reconstruções.

Nomes de Host de Destino (Gate)

Esta é a infraestrutura da vítima, não a do atacante. Eles devem ser usados para reconhecer o alvo da campanha e não devem ser bloqueados ou redirecionados (sinkholed) como se fossem maliciosos.

Comando e Controle e Preparação (Staging)

Impressão Digital da Compilação

Impacto

Para o alvo nomeado, a exposição é direta. Um ataque de confusão de dependência é bem-sucedido quando um sistema de compilação resolve um nome de pacote privado no registro público, o que ocorre devido a uma configuração incorreta, e não por erro do usuário. Qualquer compilação que resolvesse um dos 993 nomes teria executado código nativo na importação, com o implante Sliver resultante fornecendo uma capacidade de pós-exploração efetivamente completa dentro de um ambiente de compilação, que normalmente está entre os contextos mais ricos em credenciais que uma organização opera.

Para todos os outros, a lição aplicável é o reconhecimento, não o payload. O operador montou um inventário detalhado dos nomes de pacotes e serviços internos de um alvo antes de publicar qualquer coisa, e parte desse inventário era dedutível dos próprios repositórios de código aberto públicos do alvo. Qualquer organização com presença visível em código aberto e um registro privado compartilha essa exposição.

Nada nesta análise comprova um comprometimento bem-sucedido. A publicação de um nome ocupado (squatted) demonstra intenção e capacidade; não demonstra que qualquer compilação o tenha resolvido.

Recomendações

Imediato

• Aplique o escopo de registro para que namespaces privados não possam ser redirecionados para o registro público. Este é o controle que derrota toda a classe de ataque; colocar 993 nomes em uma lista de bloqueio não resolve.
• Enumere quais dos nomes do Apêndice A existem como pacotes privados em seu ambiente. Qualquer correspondência indica que o operador possuía conhecimento interno preciso.
• Bloqueie as zonas de preparação (staging) de DNS e trate as consultas TXT numeradas sequenciais como hostis, independentemente da zona envolvida.

Engenharia de Detecção

• Crie alertas para pacotes cujo ponto de entrada exija um módulo aleatório prefixado com sublinhado dentro de um bloco try/catch omitido. O nome do arquivo varia; a estrutura, não.
• Considere a montagem de nomes de host em tempo de execução a partir de fragmentos de array como um forte sinal no conteúdo do pacote. Isso existe para contornar exatamente a correspondência de indicadores realizada pela maioria das ferramentas.
• Busque pelas chaves de servidor minisign e pela impressão digital do ID do codificador, em vez de nomes de host. Ambos sobrevivem à rotação de infraestrutura.

Estratégico

• Presuma que seus repositórios públicos revelam seu namespace privado. Revise quais nomes de pacotes e serviços internos podem ser inferidos a partir de código, configuração e documentação publicados.
• Registre ou reserve defensivamente nomes de pacotes internos em registros públicos, priorizando aqueles que podem ser inferidos a partir de código aberto publicado.

Conclusão

O TXTBOOK foi inicialmente avaliado como um dropper distinguido pelo staging de carga útil via DNS. Isso estava correto, mas incompleto. O staging via DNS é como a carga útil chega. A campanha em torno dele é uma operação sustentada de confusão de dependências contra um único grupo financeiro, executada em uma escala que se assemelha a um flooding indiscriminado, sem ser, de fato, indiscriminada.

A distinção tem consequências práticas. Interpretada como flooding de registro, a resposta apropriada é bloquear uma lista de nomes. Interpretada como confusão de dependências direcionada, a resposta apropriada é corrigir a política de resolução de dependências, auditar quais nomes internos são publicamente inferíveis e tratar a lista de pacotes como um sintoma. Apenas a segunda resposta aborda os próximos 993 nomes.

O reconhecimento merece mais atenção do que a carga útil. Caminhos de serviços internos incorporados na lista de squatting indicam acesso a um inventário real dos sistemas do alvo, e uma parte adicional desse inventário era inferível a partir do próprio código aberto publicado pelo alvo, sem custo e sem risco. A parte cara desta campanha foi o reconhecimento, e ela é repetível contra qualquer organização que publique código sob uma identidade corporativa.

Os dez pacotes iniciais revelados pelo monitoramento da cadeia de suprimentos da CloudSEK foram o que tornou o restante alcançável. Cada descoberta subsequente — a infraestrutura de staging, o conjunto de comando e controle, o implante de terceiro estágio, os dois servidores de operador e o inventário de 993 pacotes — foi alcançada a partir desse ponto de partida.

Apêndice A: Inventário Completo de Pacotes

Todos os 993 nomes de pacotes atribuídos a esta campanha, agrupados por família de namespace e ordenados pelo tamanho da família. Nomes marcados com uma adaga foram identificados recentemente na varredura do corpus descrita em "Até onde a campanha alcança" e não aparecem em dados de avisos publicados anteriormente.

bnpl  (156)

dolyame  (133)

devplatform  (108)

bigops  (97)

boxy  (70)

checkout  (61)

reivindicações  (41)

tinkoff  (38)

tinkoff-statist-browser-typed-client  (28)

statist-browser-typed-client  (26)

bpm-foundation  (25)

beaver-ui  (22)

twork  (21)

entrega  (14)

pfp  (11)

cardsmobile  (9)

cobrowsing  (9)

contas  (8)

cartões  (6)

ded  (6)

sme  (6)

construtor  (5)

eacq  (5)

hubert  (5)

fb  (4)

pfa  (3)

tcb-web  (3)

a.poltoradnev  (2)

bpm  (2)

certificados  (2)

depósitos  (2)

dp  (2)

eventea  (2)

plataforma  (2)

saas  (2)

especiais  (2)

sso  (2)