common-tg-servicenpm

Malicious npm package published by user shetty123 as part of a Telegram account hijacking framework targeting Indian Telegram users. All 502 published versions (1.0.1 through 1.3.207) are malicious. Pairs with ams-ssk, which provides the operator's server-side AMS/CMS infrastructure.

common-tg-service performs full Telegram account takeover at runtime when the service is initialized (no install-time hooks, which lets it bypass scanners that gate on preinstall/postinstall lifecycle scripts). Behavior includes: implanting a hardcoded 2FA password (Ajtdmwajt1@) and recovery email on hijacked accounts; polling an operator-controlled Gmail inbox over IMAP (imap.gmail.com) to auto-submit 2FA confirmation codes; revoking all device authorizations except the attacker's session; harvesting OTP codes by monitoring Telegram chat 777000 and forwarding them to the operator; running SRP ownership checks against managed accounts and flagging rotated 2FA as unrecoverable; and fetching remote JSON configuration from npoint.io so operators can change behavior without re-publishing.

Blocked outbound requests are laundered through a relay at helper-thge.onrender.com. Stolen accounts and updates are exfiltrated to attacker-controlled Telegram channels (-1001801844217 and -1001972065816). Operator infrastructure includes paidgirl.site, cms.paidgirl.site, report-upi.netlify.app, and promoteClients2.glitch.me.

common-tg-service is a NestJS library that, when mounted into a consumer application, performs several behaviors that route installer-side data to author-controlled destinations and weaken the consumer's security posture:

1. Silent Telegram relay (dist/utils/logbots.js:24). notifbot() hardcodes Telegram chat IDs -1001801844217 and -1001972065816 as defaults for accountsChannel/updatesChannel. On NestJS module init (InitModule.onModuleInit), the package posts a 'Service Started' notification containing process.env.clientId to api.telegram.org using the consumer's own BOT_TOKENS. Unless the consumer explicitly overrides the channel env vars, the consumer's client identifier — and any further notifications routed through this helper — are delivered to chats only the author controls.

2. Bypass relay for blocked requests (dist/utils/fetchWithTimeout.js:84). When any HTTP request made through fetchWithTimeout receives a 403 or 495 response, the package falls back to POSTing the original URL, method, headers, body, and params to https://helper-thge.onrender.com/execute-request (the default when no bypassURL env is set), authenticated with the hardcoded x-api-key: santoor. Headers commonly include the consumer's auth tokens, so blocked requests result in full request material — including credentials — being silently shipped through a third-party host controlled by the author.

3. ZIP extraction from author-controlled host into the consumer CWD (dist/cloudinary.js). CloudinaryService.getResourcesFromFolder fetches a ZIP from https://cms.paidgirl.site/folders/<folder>/files/download-all and extracts it into process.cwd() using adm-zip with no integrity check and no path-traversal protection. Whatever bytes that host returns become files in the consumer's working directory and could be picked up by subsequent require() / build steps.

4. Hardcoded auth-bypass key (dist/guards/auth.guard.js). AuthGuard.canActivate accepts the literal string santoor as a valid x-api-key, granting access to any route protected by the guard. Every consumer that mounts this AuthGuard inherits a publicly-known backdoor key that allows anyone to bypass authentication on their service.

Collectively this is silent-relay of consumer data plus an authentication backdoor. Each behavior fires either on module init or via normal consumer use of the exported APIs, with no opt-in.