tinkoff-cloud-apis-internalPyPI
tinkoff-cloud-apis-internal is a confirmed malicious PyPI package (MAL-2026-10917) that steals credentials and exfiltrates sensitive data (malicious versions 0.0.1, 8.5.3, 8.5.4). Do not install it — remove it immediately and rotate any exposed credentials.
Malicious code in tinkoff-cloud-apis-internal (PyPI)
What this malware does
The package installs a telemetry.pth file into site-packages via a custom install cmdclass; the.pth line imports _telemetry_init, causing every subsequent Python interpreter startup on the host to spawn a background thread that fetches and executes attacker-controlled binaries. The bootstrap resolves platform-specific payload paths (/pkg/package, /pkg/package-arm64, /pkg/loader_mac, /pkg/package.exe) from a rotating set of anonymous Cloudflare Workers mirrors (package-proxy.cf5oobworker.workers.dev, cf8oobworker, cf12oobworker, cf17-ddb, cf25-6eb.workers.dev) with a DNS-over-UDP TXT covert-channel fallback (tin.dl.well1.site, tina.dl.well1.site, ldr.dl.well1.site, win.dl.well1.site queried against 8.8.8.8/1.1.1.1, base64-reassembled from chunked TXT records). Downloaded bytes are chmod 0o755 and executed on Unix, or launched via ctypes.windll.kernel32.CreateProcess with hand-built STARTUPINFO/PROCESS_INFORMATION structs on Windows, with no signature or hash verification. The module mimics the Sentry Python SDK surface (DSN, Envelope, Hub, Scope, BreadcrumbRecorder, capture_message, capture_exception) and self-describes as a 'Platform analytics SDK' with a DISABLE_TELEMETRY opt-out; the package name tinkoff-cloud-apis-internal and generic 'Platform Engineering' author metadata impersonate internal infrastructure of a well-known Russian financial-services provider.
Package presents little functionality, but excessive fake 'telemetry' module. This fake telemetry is used to download and run malicious executables. Code is designed to survive different blocks: first, there is an attempt to download the executable from one of five Cloudflare Workers. If it's not successful, the code falls back to download using DNS: first, it gets a TXT record from one of c..dl.well1[.]site domains, depending on the system. This record returns a number, which is then used to iterate over domains in the form <0...n>..dl.well1[.]site and reconstruct the encoded executable from their TXT records. The downloaded binary is then executed and removed afterward. Using a PTH file ensures persistence and runs on every Python start. In this campaign, versions 0.0.1 hold disarmed code (without the necessary configuration), which is completed in further updates.
This is a continuation of the 2026-07-haproxy-config-client campaign.
Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers.
Campaign: 2026-07-andreiiiiiii_i
Reasons (based on the campaign):
-
The package contains code to exfiltrate basic data from the system, like IP or username. It has a limited risk.
-
The package overrides the install command in setup.py to execute malicious code during installation.
-
Downloads and executes a remote executable.
-
covering-tracks
-
persistence
-
abuses-pth
-
data-stored-in-dns
Malicious versions
Indicators of compromise (SHA-256)
Detection & response playbook
Credential / info stealerFind it
Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for tinkoff-cloud-apis-internal (3 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging tinkoff-cloud-apis-internal across your stack and pipelines.
If you installed it — respond
tinkoff-cloud-apis-internal is built to steal secrets, so assume every credential the build or runtime could read is compromised. Remove it from your project and lockfile, then rotate ALL exposed secrets — npm/registry tokens, cloud keys, CI/CD secrets, SSH keys, and any .env values — from a known-clean machine. Audit logs for unauthorized use of those credentials.
Did it already run?
If tinkoff-cloud-apis-internal was ever installed, its post-install/runtime payload may have already executed. O3's L7 egress monitoring and runtime eBPF sensors detect the credential exfiltration or command-and-control callback after install and block the malicious outbound channel, so you catch and contain the actual compromise — not just the presence of the package.
How O3 protects you
O3 blocks tinkoff-cloud-apis-internal before install through its supply-chain scanner, and if it has already run, detects and severs the exfiltration or C2 callback at runtime through L7 egress monitoring and eBPF.
Frequently asked questions
Campaign
References
Credits
- Amazon Inspector · finder
- Kamil Mańkowski (kam193) · reporter
Detect & block this
O3 blocks tinkoff-cloud-apis-internal-class packages before install and in CI — and if it already ran, its runtime egress monitoring catches the credential exfiltration and severs the channel.