ams-ssknpm
Malicious code in ams-ssk (npm) Remove it immediately and rotate any exposed credentials.
What this malware does
Malicious npm package published by user shetty123 as part of a Telegram account hijacking framework targeting Indian Telegram users. All 31 published versions (1.0.0 through 1.0.33) are malicious. Pairs with common-tg-service, which performs the client-side Telegram account takeover.
ams-ssk is the server-side AMS/CMS infrastructure for the operation. It exposes a file-management CRUD API including a bulk-zip download endpoint (folders/:folder/files/download-all) and a multi-bot Telegram message-forwarder with per-bot operation counters used to fan out hijacked-account traffic. Observed deployments include cms.paidgirl.site and promoteClients2.glitch.me. The package is part of an actor-controlled stack (operator identity shetty123 / display name Mad_man) used to manage stolen Telegram accounts and exfiltrate data to attacker-controlled Telegram channels (-1001801844217, -1001972065816).
Malice executes at runtime when the service is initialized; there are no preinstall/postinstall lifecycle scripts, so the package bypasses install-time scanners.
The package ams-ssk was found to contain malicious code.
Malicious versions
Every published version of this package is considered malicious — remove it entirely.
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 ams-ssk (all published versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging ams-ssk across your stack and pipelines.
If you installed it — respond
ams-ssk 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 ams-ssk 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 ams-ssk 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
References
Credits
- Amazon Inspector · finder
- SafeDep · finder
Detect & block this
O3 blocks ams-ssk-class packages before install and in CI — and if it already ran, its runtime egress monitoring catches the credential exfiltration and severs the channel.