🚨 TRONIFY.RENT - WALLET DRAINER ANALYSIS

Executive Summary Report

THREAT LEVEL: CRITICAL MALICIOUS

tronify.rent is a wallet draining service disguised as a legitimate TRON energy rental platform. It systematically extracts cryptocurrency assets from connected wallets through token approval exploitation and TRX sweeping.

Quick Facts

Attribute	Details
Domain	tronify.rent
Registered Company	Tronify Energy Solutions LLC (Florida, EIN: 87-2945163)
Malicious Payload	greenbid.js (150KB minified JavaScript)
Payload Host	https://lending.fhogu.pw/greenbid.js?v=1
Attack Method	Token approval + TRX sweep + backend exfiltration
Targeted Wallets	Trust Wallet, TronLink, OKX Wallet, TokenPocket, Bitget, SafePal, WalletConnect (verified from the live payload's wallet array — not MetaMask, contrary to an earlier draft of this report)
Blockchain	TRON Network (TRC-20 tokens, TRX native)
Current attacker addresses	tronSpender: `TV6n8cCLmX5mRCMMNvcE1K1i87Yo9Ys5rv` · tronSweepAddress: `TLv3iSnZxWghEmadLDzuAK2p5GkAwg7tpJ` (fetched live from C&C on 2026-09-20; attacker can rotate these — see IoCs doc)
Status	Verified active and currently exploiting victims as of 2026-09-20 — confirmed by pulling the live payload, live C&C config, and on-chain transaction history for the attacker's own addresses (see "On-Chain Confirmation" below)

What Happened?

The Attack in 3 Steps:

Social Engineering: Users visit tronify.rent believing it's a legitimate energy rental service. The site claims to save 97% on transaction fees.
Wallet Connection: Users click "Connect Wallet" and approve connection through TronLink, WalletConnect, or other TRON wallets.
Automated Draining: The greenbid.js payload runs in the browser, automatically:
- Analyzes all TRC-20 tokens in the wallet
- Requests approval (token spending permission) from the user
- Transfers all approved tokens to attacker-controlled addresses
- Sweeps remaining TRX balance to attacker address
- Logs all activity to backend servers for attacker tracking

Key Evidence

1. Explicit Draining Code References

The greenbid.js payload contains 8 explicit logging statements for "drain" functionality. These are the exact strings, byte-for-byte, extracted from the live payload we downloaded and hashed (SHA-256 0f6d64472d6369a098f403db117b1285e79b0fdac79caaa639fc0e50e5bf4416):

Y("drain","no tron spender configured") Y("drain",`found ${n.length} tokens`) Y("drain",`${r.symbol}: already approved`) Y("drain",`TRX balance: ${B} sun, min: ${h} sun`) Y("drain",`sweeping ${u} sun TRX`) Y("drain",`TRX sweep result: ${JSON.stringify(v)`) Y("drain",`TRX sweep error: ${E==null?void 0:E.message}`) Y("drain","TRX sweep timed out — skipping")

Note the approval mechanism specifically calls the TRC-20 increaseApproval(spender, amount) method (not the more commonly documented approve()) — confirmed directly in the payload as B.increaseApproval(e.tronSpender,"11579208923...639935").

2. Backend Command & Control Infrastructure

The script communicates with attacker-controlled servers via 12 distinct endpoints (all extracted directly from the live payload — 4 more than an earlier draft of this report found):

/tron/config // Fetch spender address & sweep config /tron/balances/{address} // Fetch victim's token balances (attacker's own backend, not TronGrid directly) /tron/notify/wallet-connected // Log victim wallet connection /tron/notify/visit // Log page visit (even before wallet connect) /tron/approve/notify // Log token approvals /tron/notify/sweep // Log TRX sweep transaction /tron/notify/approve-rejected // Track failed approvals /tron/notify/tx-proposed // Log a proposed transaction before signing /tron/funding/initiate // Attacker sends victim TRX for gas — see "Gas-Funding" below /tron/funding/status/{address} // Poll whether that gas funding has landed /tron/client-log // General-purpose telemetry: ships every console-style log, not just "drain"-tagged ones /tron/walletconnect // Proxies WalletConnect session handling through the attacker's backend

New finding — attacker-funded gas ("priming"): If a victim's wallet holds valuable USDT but has less than 30 TRX (not enough to pay approval/transfer fees), the payload calls /tron/funding/initiate and the attacker's backend sends the victim ~15 TRX directly, then polls /tron/funding/status until it lands, before continuing the drain. The attacker is willing to front real money to unlock a high-value wallet that would otherwise be stuck. This is a stronger and more specific on-chain signal than a generic "cascading transfer" pattern — see the IoCs document.

3. Multi-Wallet Support

The drainer's wallet-detection array, extracted verbatim from the live payload, lists these 7 providers in this exact order:

Wallet Provider	Detection Method	Status
Trust Wallet	window.trustwallet OR window.ethereum.isTrust	First in array
TronLink	window.tronLink object	Primary target (16 references in payload)
OKX Wallet	window.okxwallet	Supported
TokenPocket	window.tokenpocket OR window.ethereum.isTokenPocket	Supported
Bitget (formerly BitKeep)	window.ethereum.isBitKeep	Supported
SafePal	window.safepalProvider OR window.ethereum.isSafePal	Supported
WalletConnect	WalletConnect protocol (proxied via /tron/walletconnect)	Supported

Correction: an earlier draft of this report listed "MetaMask (TRON chain)" as a target, attributing the window.ethereum.isTrust check to it. That check is actually part of Trust Wallet's detection (Trust Wallet's injected provider sets isTrust=true). MetaMask does not appear anywhere in the live payload (0 matches).

Attack Timeline

User visits tronify.rent → Legitimate-looking energy rental interface loads
Clicks "Connect Wallet" → TronLink/WalletConnect dialog appears
Approves wallet connection → Site gains access to wallet address & signing capabilities
greenbid.js executes in browser → Payload initialized with attacker config
Wallet analysis → Script enumerates all TRC-20 tokens & TRX balance
Token approvals → User sees wallet notifications requesting token spending approvals
User confirms → Each confirmation grants spender contract unlimited access
Automated transfer → Tokens transferred to attacker address (tronSweepAddress)
TRX sweep → Remaining native TRX sent to attacker (with 2 TRX fee kept for next victim)
Logging & tracking → All activity reported to C&C servers via /tron/* endpoints

Why This Works

Social Engineering: Legitimate-looking interface with real company name, address, phone number
User Expectations: Token approval requests appear normal for DeFi operations
Browser Execution: JavaScript runs with full access to connected wallet APIs
Non-Custodial Claim: Users believe they "control their keys" - the site never asks for seed phrase
Automation: Once wallet connected, script runs autonomously without further user interaction
Reversibility Problem: Once approved, token transfers cannot be blocked (no on-chain way to prevent)

Confirmed Indicators

✓ 150KB JavaScript payload with 8 explicit "drain" logging statements
✓ Command & Control endpoints for victim tracking (/tron/config, /tron/notify/*, etc.)
✓ Multi-wallet provider compatibility code (TronLink, WalletConnect, Trust, SafePal)
✓ Automated token enumeration & unlimited approval requests
✓ TRX balance sweeping to attacker-configured address
✓ Visitor ID generation for campaign tracking
✓ Retry logic for approval requests with exponential backoff

Impact Assessment

Impact Category	Severity	Details
Asset Theft	CRITICAL	100% of approved token value + all TRX balance transferred
Wallet Compromise	CRITICAL	Attacker gains spender permissions on all TRC-20 tokens
User Data Exfiltration	HIGH	Wallet addresses, IP, user-agent, transaction history logged
Account Takeover	MEDIUM	If wallet is connected to centralized exchanges, downstream risk
Financial Loss Scale	CONFIRMED (lower bound), true total unknown	On 2026-09-20 we found the current sweep address's 30 most recent USDT inflows alone total ~$32,560, from ~25 distinct sender wallets, spanning 2026-08-27 to 2026-09-19. That address and the spender address together currently hold ~46,900 USDT + ~4,089 TRX unspent. This is a floor, not a ceiling — older transfers exist beyond this page of history, and the spender/sweep addresses have already sent ~30,500 USDT onward (two transfers of 24,000 and 6,000 USDT) to other addresses we did not trace further.

On-Chain Confirmation (New — 2026-09-20)

Because the C&C's /tron/config endpoint is live and unauthenticated, we retrieved the attacker's actual current addresses and checked them directly on TronGrid/TronScan. Raw API responses are preserved in evidence/onchain/ and evidence/cnc/ with checksums in evidence/SHA256SUMS.txt. Key findings:

Both the spender (TV6n8c...Ys5rv) and sweep (TLv3iS...g7tpJ) addresses were created within 39 seconds of each other on 2026-07-23 — clearly provisioned together as one attacker toolkit.
The spender address's last on-chain activity was 2026-09-19 22:12 — the day before this report.
The sweep address shows a clear victim-in / consolidation-out pattern: ~25 distinct wallets sent USDT in over ~3 weeks, and the attacker periodically moves large batches out (24,000 USDT and 6,000 USDT observed) to separate consolidation addresses.
The "tronExchangeContract" address is a deployed smart contract (not a wallet) whose on-chain name decodes to "TronEnergy" — likely the mechanism used to make the site's energy-rental claim appear at least partially functional.

Next Steps for Users

If you connected your wallet to tronify.rent:

Check your wallet's "token approvals" and revoke any suspicious contracts
Review your TRON transaction history (tronscan.org) for any unauthorized transfers
If unauthorized transfers are found, move remaining assets to a new wallet
Report the incident to your wallet provider
See Defense & Remediation guide for detailed steps

For Security Researchers

Continue to:

Technical Architecture - Deep dive into how the drainer works
Attack Chain - Step-by-step exploitation process
Code Analysis - Detailed breakdown of greenbid.js
IoCs - Detection signatures and hunting techniques

Attribution Notes

As of September 2026, the attacker identity is unknown. The registered company "Tronify Energy Solutions LLC" (EIN 87-2945163, Orlando FL) shown on tronify.rent could not be confirmed or refuted against Florida's Sunbiz registry in this pass — that specific claim remains unverified, not proven stolen or proven genuine.

Brand-squatting angle (new finding): "Tronify" is a real, actively-used brand name in the TRON energy-rental space — a service by that name is reported (via a third-party crypto news article) to be integrated with Trust Wallet, and live product/documentation sites exist at tronify.io/tronify.ai and a GitBook. Several other tronify-named domains we checked (tronify.app, tronify.llc, tronified.com) currently return no DNS record at all, and tronify.pro resolves but 302-redirects to google.com — i.e. dead/abandoned. tronify.rent is not impersonating one specific still-live competitor; it's squatting on a busy, partly-abandoned brand namespace where "is Tronify legit" searches surface genuinely positive signals that don't distinguish between TLDs. This materially increases the effectiveness of the social-engineering angle beyond "professional-sounding fake name."

Infrastructure: the frontend (tronify.rent) is fronted by DDoS-Guard; the payload host (lending.fhogu.pw) is fronted by Cloudflare — two different reverse-proxy providers for the two tiers of infrastructure, both of which obscure the true origin server IP.