Supermarket freezer attacks have moved beyond France. Overnight into Monday, November 2, 2026, refrigeration systems at dozens of stores in Belgium, Luxembourg and Sweden showed sudden temperature rises, with some freezers set as high as 50°C. Retailers threw out spoiled stock, and several stores opened late or stayed closed for the morning.
The incidents are suspected cyberattacks. Sweden’s national cybersecurity center says it is responding to multiple incidents involving store cooling systems, and the refrigeration contractor that runs Delhaize’s installations in Belgium has called the Belgian events a cyberattack. As of November 2, no group has claimed responsibility, and no authority has named a suspect or an entry point.
Which Retailers Reported Problems?
Reports from retailers, local media and wire services put the scope as follows. Store counts vary between outlets, so the table gives the range where they differ.
Country
Retailer
Reported Impact
Belgium and Luxembourg
Delhaize (Ahold Delhaize)
About 40 stores; the company describes an “IT incident” affecting fridges and freezers
Belgium
Carrefour Belgium
15 stores; all remained open
Belgium
Spar stores operated under Colruyt Group franchise
Five shops; smaller Proxy Delhaize and Shop & Go outlets were also reported
Sweden
ICA
“A limited number” of stores operating outside ICA’s central network
Sweden
Coop
Six or seven of roughly 800 stores; Coop says the situation is contained
Estonia
Unnamed grocery chain
Temperatures set to 50°C, as reported by its refrigeration technology supplier
Store-level losses are already significant. One Delhaize store in Hoeilaart, Flemish Brabant, put its lost produce at €100,000, not counting revenue lost while closed. A Stockholm ICA store said the attack hit at 2 a.m. and staff noticed it at 5:30 a.m., and stores in Sjöbo and Tomelilla in southern Sweden stayed shut for the morning.
What Happened Inside the Cooling Systems?
The clearest technical account so far comes from Belgium. Stephan Moelans, CEO of refrigeration contractor Sabcobel, which operates Delhaize’s installations, told Belgian news agency Belga that the units’ evaporators had been switched into defrost mode. He said Sabcobel started sending technicians at 1 a.m. and spent the night and morning disconnecting the affected installations.
In Sweden, one ICA store posted that its fridge and freezer temperatures had been “hacked” overnight and set to 50°C. Another store wrote that the settings matched those seen during the French attack.
Neither retailers nor authorities have named the controller brands involved in these incidents. That matters: in France, more than one vendor’s equipment was targeted, so it is not safe to assume the same product line was hit in Belgium or Sweden.
Is This Confirmed as a Cyberattack?
Not formally. The evidence so far points toward remote tampering, but the wording from each party differs:
Sweden’s national cybersecurity center: Head John Billow confirmed the center is working on several incidents affecting grocery refrigeration and said Sweden has “quite a lot of exposed operational technology devices” that need updating or patching
Belgian refrigeration contractor: Sabcobel’s CEO described the Belgian events as a cyberattack
Ahold Delhaize: Calls it an IT incident under investigation
ICA and Coop: Confirm overnight incidents affecting refrigeration and freezer systems at a limited number of stores
Belgian and Swedish national cyber agencies: Both say they are monitoring the incidents
Ahold Delhaize separately dealt with an October security issue that forced it to shut down and later restore some IT systems, and it reported suspicious activity to Dutch police last month. No source has linked that earlier incident to the refrigeration problems.
The Same Overnight Pattern, Three Times in Three Months
The November incidents look like the French supermarket cyberattack of October 11 to 12, and both resemble refrigeration failures at U.S. military commissaries in August. A shared attacker has not been established for any of them.
The table below compares the three recent freezer attacks in detail, including the equipment named so far, which has been disclosed only for France.
Up to about 700 supermarkets, per the French government
Observed effect
Forced defrost cycles and temperatures around 50°C; food losses and fires
Equipment named
Danfoss AK-SM and AK-SC, Copeland xweb and Dixell xweb controllers
Status
Confirmed compromises Paris prosecutor investigating
Latest
Belgium, Luxembourg, Sweden
Night of November 1 to 2, 2026
Scale
Dozens of stores
Observed effect
Defrost mode and setpoints of 50°C
Equipment named
Not disclosed
Status
Suspected National agencies responding
No shared attacker has been established across the three waves. Status as of November 2, 2026.
The U.S. Army’s Criminal Investigation Division has said it is working with French law enforcement to understand the European outages. That coordination does not show the incidents share an attacker. Separate open-source analysis has also traced the unclaimed pattern from the commissaries to France.
Why Refrigeration Controllers Keep Getting Hit
Large stores run their refrigeration through centralized controllers that manage setpoints, alarms and defrost schedules for every case and cold room. Maintenance firms often reach these controllers remotely, and some sit directly on the internet with a web management interface.
France’s CERT-FR alert on the October attack warned that exposing these interfaces goes against basic practice and that the campaign was probably still ongoing. It said an end-of-life controller left online has a very high chance of compromise, and that a factory reset alone does not help, because the device stays vulnerable and is likely to be hit again. SOCRadar’s own October snapshot found roughly 2,900 exposed Danfoss StoreView services in France alone.
The risk is not limited to one country. Swedish officials now say they have many exposed operational technology (OT) devices to fix, and retailers often depend on contractors who control the remote access path.
Who Could Be Behind It?
No group has claimed the French, U.S. or new European incidents, and no government has attributed them. The attacks so far show no ransom demand or data theft, which makes disruption the more likely goal than profit.
Commentators have raised state-backed sabotage as one explanation, while others note that unsecured controllers are within reach of low-skilled actors. Both readings remain possible. Until there is a credible claim or official attribution, any link to a named group should be treated as speculation.
What Retailers and Refrigeration Contractors Should Check Now
CERT-FR’s guidance from the French incident applies to any retailer running remotely managed refrigeration, whatever the vendor:
Remove refrigeration controllers from direct internet exposure, including any unit on a public IP address
Restore remote access only through a secured VPN or protected network; filtering contractor source IPs is an emergency measure, not a fix
Review the full controller configuration, especially defrost schedules, temperature setpoints and alarm settings
If a controller shows signs of tampering, restart or factory reset it and reconfigure it before reconnecting, but only after the exposure is closed
Update firmware, apply the vendor’s strictest security mode where one exists and confirm default passwords are changed
Plan replacement of end-of-life controllers that no longer receive updates
Retailers should also ask their refrigeration contractors how they connect to each store and who holds those credentials. Independent temperature alarms that do not depend on the controller give staff a second warning at night, when every one of these incidents began.
Protect Your OT Systems and Supply Chain with SOCRadar
In every country hit so far, the attacks targeted refrigeration controllers managed remotely by contractors. CERT-FR found the compromised French controllers exposed to the internet, and Sweden’s cybersecurity center reports many exposed OT devices still waiting for updates. Security teams rarely see these systems. SOCRadar helps close that gap in three ways:
Attack Surface Management: Finds refrigeration management interfaces and remote access services exposed across your IP space, including ones a contractor set up without your security team’s knowledge, so you can take them offline before attackers find them
Supply Chain Intelligence: Tracks the security posture of refrigeration contractors and other OT service providers, and flags when a supplier you depend on shows signs of compromise
Dark Web Monitoring: Watches hacktivist channels and underground forums for attack claims, leaked access or chatter that names your brand, your suppliers or the food retail sector
External visibility shows where you are exposed and who is talking about you, but only a controller’s own configuration and event logs can confirm whether it was changed. Every one of these incidents happened overnight, when no one was watching the cases. Taking exposed controllers off the internet and reviewing contractor access now is the best preparation for the next wave.
The Binance hack drained an estimated $6.3 billion from the exchange’s hot wallets across roughly 10 blockchains on the evening of October 29, 2026. The Binance hack is a hot wallet compromise in which an attacker made Binance’s own withdrawal infrastructure sign and send funds to attacker-controlled addresses, mostly within about 20 minutes.
Binance has confirmed the incident, and the evidence points to a serious, well-resourced operation: staged in advance, executed across chains at once, and built to get unauthorized transactions through the controls meant to stop them. About $3 billion has been blocked through on-chain freezes, and Binance has committed to paying for the rest.
Key Takeaways
Record loss: Binance estimates the impact of the October 29, 2026 hot wallet theft at around $6.3 billion, about four times the $1.5 billion Bybit theft and the largest crypto heist on record
Highly prepared operation: The attacker drained about 10 blockchains in roughly 20 minutes, with withdrawals pushed through Binance’s own signing path as if they were legitimate
Entry point: Binance first linked the breach to a compromised DevOps engineer’s laptop, then said its investigation uncovered additional points of breach in what it calls a complex attack
Half contained: About $3 billion is frozen on-chain, and Binance has reserved more than $6.34 billion in company funds to cover losses
Attribution: Two blockchain analytics firms link the theft to North Korea’s TraderTraitor; Binance and governments have not confirmed attribution
Binance Hack at a Glance
Incident
Unauthorized hot wallet withdrawals at Binance
Date
October 29, 2026, starting around 20:05 UTC
Estimated Loss
Around $6.3 billion (Binance estimate); independent estimates range from $6.36 billion to $6.4 billion
Blockchains Affected
About 10, including Ethereum, Bitcoin, Tron, XRP Ledger, Solana, Arbitrum, Optimism, Base, Avalanche and Polygon
Initial Access (Preliminary)
Compromised DevOps engineer laptop plus additional points of breach (Binance, October 30, 2026); full root cause not yet published
Private Key Exposure
No evidence found (Binance)
Frozen So Far
About $3 billion on-chain (Binance)
Loss Coverage
More than $6.34 billion in company funds reserved; about $5 billion already held in the stolen token types
Attribution
Assessed by blockchain analysts as TraderTraitor (North Korea); not confirmed by Binance or governments
Service Status
Withdrawals paused while the service is rebuilt and retested; Binance expects them back before Sunday, November 1, 2026; deposits unaffected
Binance Hack Timeline
October 30, 2026 Binance
Binance reserves $6.34 billion and targets Proof of Reserves by Monday
Binance says it has reserved more than $6.34 billion in company funds, about $5 billion of it already held in the stolen token types, and is buying the rest through market and OTC channels. Co-CEO Richard Teng says the attack was not carried out by one person, the attacker used a self-destruct mechanism to wipe tooling and traces, and a full Proof of Reserves report is planned for Monday.
October 30, 2026, 08:47 UTC Binance
Binance finds additional points of breach
Binance says its investigation has uncovered additional points of breach beyond the compromised laptop identified earlier, calling it a complex attack. The outflows stopped when withdrawals were paused, about $3 billion is frozen, and withdrawals remain on track to resume in about 45 hours. Deposits are unaffected.
October 30, 2026, 04:17 UTC Status
Withdrawals expected to resume within 48 hours
Binance co-CEO Yi He says withdrawals remain paused while the team improves controls on the withdrawal service and related addresses, and should begin resuming within 48 hours. Deposits are operating normally.
October 30, 2026, early morning UTC Attribution
Second firm links the theft to TraderTraitor and a possible Bitget connection emerges
Attribution: A second blockchain analytics firm says North Korea’s TraderTraitor likely carried out the hack and raises its loss estimate to about $6.4 billion
Bitget link: An independent investigator finds that funds from the Binance hack and the September 2026 Bitget exploit were mixed at the same address after passing through THORChain
October 30, 2026, 02:23 UTC Binance
Binance publishes its Security Incident Update
Binance’s initial investigation suggests a compromised DevOps engineer’s laptop gave the attacker access to a service container that submitted unauthorized withdrawals. Binance says it found no evidence of a wallet private key leak, estimates the impact at around $6.3 billion with about $3 billion frozen on-chain, and will cover all losses from SAFU and company funds.
October 30, 2026, 00:30 UTC Attribution
Blockchain analysts attribute the theft to TraderTraitor
Blockchain analysts attribute the theft with high confidence to North Korea’s TraderTraitor and value the stolen assets at $6.36 billion. As of 00:30 UTC, about $2.4 billion remains under attacker control, mostly more than 420,000 ETH and 18,270 BTC. Binance and government agencies have not confirmed the attribution.
October 30, 2026, 00:08 UTC Response
Arbitrum Security Council moves funds out of an attacker wallet
The council forces 8,426 ETH and 74.6 million ARB, worth about $30 million, out of the attacker’s Arbitrum wallet.
October 29, 2026, 23:05 UTC Attack
Second wave hits Avalanche and Polygon
Binance wallets on Avalanche and Polygon send out funds in a second wave, and smaller sweeps continue until about 23:56 UTC.
October 29, 2026, about 22:30 UTC Binance
Binance confirms a security incident and pauses withdrawals
Binance suspends withdrawals on multiple networks as a precaution, says user funds are safe, and warns users not to trust unofficial links or messages about the incident.
October 29, 2026, 22:01 to 22:26 UTC Response
Ripple and World Liberty Financial freeze stablecoins
Ripple freezes the RLUSD the attacker had not yet sold, and World Liberty Financial freezes 27.8 million USD1 in the attacker’s main receiving wallet.
October 29, 2026, 21:01 to 21:04 UTC Response
Tether and Circle freeze about $1.8 billion
Within about 40 minutes of the main Ethereum sweep, Tether freezes 971.1 million USDT in the attacker’s main receiving wallet and Circle freezes 823 million USDC, in coordination with law enforcement.
October 29, 2026, 20:20 to 20:24 UTC Attack
Ethereum hot wallet emptied in under four minutes
EIP-7702 sweep: One transaction carries 50 authorizations signed by a Binance Ethereum hot wallet, each pointing to an attacker-controlled sweeper contract
Main drain: About three and a half minutes later, 167,464 ETH and 1.615 billion USDT leave the wallet
Other chains: 18,270 BTC and 612.7 million USDT on Tron leave Binance in the same window
October 29, 2026, 20:05 UTC Attack
Multi-chain drain begins
Five Binance wallets send 233.46 million XRP to a single attacker address. Within roughly 20 minutes, Binance wallets on about 10 blockchains have sent funds out.
October 28, 2026 Staging
Attacker prepares an operator wallet
A fresh operator wallet starts receiving small Tornado Cash withdrawals on the morning of October 28, and the attack code is deployed and tested early on October 29.
What Happened in the Binance Hack?
Attackers pushed unauthorized withdrawal transactions through Binance’s hot wallet infrastructure on October 29, 2026, moving an estimated $6.3 billion in crypto to attacker-controlled wallets. The outflows hit about 10 blockchains at once. Binance confirmed a security incident, suspended withdrawals, and revoked authorization for the affected address.
What Did Binance Say in Its Official Statement?
Binance published a Security Incident Update on October 30, 2026, laying out its preliminary findings and response. The key points:
Initial finding: The initial investigation suggests the incident may involve a compromised DevOps engineer’s laptop, which let the attacker reach a service container and submit unauthorized withdrawal transactions
Keys: Binance has found no evidence of any wallet private key leak
Impact: The estimated total impact is around $6.3 billion, with about $3 billion frozen on-chain through blockchain partners
Coverage: Binance will cover all losses from the SAFU fund and company funds, and says user funds are safe
Containment: Binance suspended deposits and withdrawals during security checks and revoked the affected address authorization
Next steps: Law enforcement and blockchain intelligence partners are engaged, and Binance will publish a technical post-mortem and an updated Proof of Reserves
In an October 30 update at 08:47 UTC, Binance said its investigation had identified additional points of breach beyond the laptop, indicating a more complex attack. The exchange confirmed that outflows stopped after withdrawals were suspended, approximately $3 billion remains frozen, and asset recovery for affected users is underway. Binance is also cooperating with law enforcement. In a video statement, co-CEO Richard Teng said the attack “was not carried out by one person.”
How Did Attackers Get Into Binance’s Systems?
Binance first traced the breach to a compromised DevOps engineer’s laptop, which gave the attacker access to a service container that could submit withdrawal transactions. The company adds that the compromised computer was only the first stage, and that its investigation has not assigned responsibility to any individual employee. Its latest update goes further: the investigation has uncovered additional points of breach, which Binance describes as part of a complex attack.
As of October 30, 2026, Binance has not said what the additional points of breach are or published a full root cause.
How Sophisticated Was the Binance Attack?
The on-chain evidence points to a carefully engineered operation. Blockchain tracing shows the attacker funded an operator wallet on October 28, then deployed and tested code early on October 29. When the theft began, Binance wallets on about 10 chains sent funds out within roughly 20 minutes.
The withdrawals carried valid signatures from Binance’s own hot wallet infrastructure, so the approval path that should have blocked them signed them instead. Analysts assess that the attacker gained the ability to make Binance’s signing system approve transactions of its choosing across chains. Binance itself now describes the incident as a complex attack involving more than one point of breach. Co-CEO Richard Teng added that the attacker used a self-destruct mechanism that destroyed tooling and traces along the way, making the investigation harder.
How Much Crypto Was Stolen From Binance?
Binance puts the total impact at around $6.3 billion. Independent tracing values the stolen assets at $6.36 billion at the moment they were taken, and another analytics firm raised its estimate to about $6.4 billion on October 30. The gap reflects different pricing snapshots and timing.
Estimated value of assets taken from Binance by blockchain at the time of theft, with Binance’s impact and freeze estimates.
When Did the Binance Hack Happen?
The first unauthorized transfers began around 20:05 UTC on October 29, 2026, when five Binance wallets sent XRP to a single attacker address. Bitcoin, Tron, Solana and Ethereum outflows followed within roughly 20 minutes. A second wave hit Avalanche and Polygon around 23:05 UTC, and smaller sweeps continued until about 23:56 UTC.
Short timeline of Binance’s hack, from attacker staging on October 28 to Binance’s service update on October 30, 2026.
What Role Did EIP-7702 Play in the Ethereum Drain?
EIP-7702, an Ethereum feature that lets a regular account delegate its behavior to smart contract code, was used to empty one of Binance’s Ethereum hot wallets. The attacker submitted a single transaction carrying 50 authorizations signed by that wallet, each pointing to an attacker-controlled sweeper contract.
The 50 authorizations covered consecutive nonces, guaranteeing one would be valid at execution time. About three and a half minutes later, the wallet’s full balance, including 167,464 ETH and 1.615 billion USDT, moved to the attacker. EIP-7702 only provided the sweep mechanism; the authorizations still carried the hot wallet’s signature. Binance says the delegation did not pass through its normal approval controls.
Were Binance Private Keys Leaked?
Binance says it has found no evidence of any wallet private key leak. The on-chain pattern is consistent with that: apart from the EIP-7702 sweep, funds on Ethereum and the other chains left through ordinary signed transfers. That pattern fits an attacker who controlled what the signing system approved, rather than one holding stolen keys.
Who Is Behind the Binance Hack?
Blockchain analysts attribute the theft with high confidence to TraderTraitor, a North Korean state-backed cluster often grouped under the Lazarus umbrella. Their assessment cites on-chain and off-chain intelligence and overlaps with earlier thefts, including small Tornado Cash withdrawals for staging and signatures obtained in advance. A second analytics firm says TraderTraitor likely carried it out.
Other investigators are more cautious. One person familiar with crypto investigations told reporters the theft is not yet definitively attributed. As of October 30, 2026, neither Binance nor any government agency has publicly named the attackers.
Is the Binance Hack Linked to the Bitget Hack?
Possibly. An independent on-chain investigator found that funds from the Binance hack and from the September 2026 Bitget exploit were commingled at the same address after passing through THORChain, and said the same actor is likely behind both. Bitget had already said it suspected North Korean attackers in its roughly $387 million loss. Neither exchange has confirmed a shared attacker.
How Much of the Stolen Crypto Has Been Frozen?
Binance reports about $3 billion frozen on-chain as of October 30, 2026, close to half of the estimated loss. Stablecoin issuers did most of the work because they can blacklist addresses holding their tokens, and the first large freezes landed within about 40 minutes of the main Ethereum sweep.
Tether: Froze more than $1.567 billion in USDT tied to the theft
Circle: Froze more than $800 million in USDC, in coordination with law enforcement
Other issuers and protocols: Ripple froze RLUSD, World Liberty Financial froze USD1, First Digital froze FDUSD, and Aave froze affected lending markets
Arbitrum Security Council: Forced about $30 million in ETH and ARB out of an attacker wallet
Where Is the Rest of the Stolen Money Going?
Roughly $2.4 billion remained under attacker control as of 00:30 UTC on October 30, 2026, mostly more than 420,000 ETH and 18,270 BTC. The bitcoin is moving through a peel chain that splits it into 1,000 BTC and 100 BTC pieces.
The cash-out moved fast, and the attacker accepted heavy losses to stay ahead of the freezes:
Discounted swaps: About 325 million USDT went to market makers through UniswapX and other intent-based contracts for roughly 122,300 ETH, an implied price near $2,650 per ETH while ether traded around $2,300 to $2,350, a discount of more than 10%
DeFi borrowing: A second wallet supplied 60 million USDT to Aave and borrowed about 19,760 ETH before Aave froze the affected markets
Tron routing: 300 million USDT moved to a wallet supplying JustLend, while another 200 million USDT passed through hop wallets to Uniswap, where 30 million was frozen
Stablecoin dumping: About 48 million RLUSD was sold on decentralized exchanges between 21:42 and 22:01 UTC, until Ripple froze the remaining 40.5 million
Later reporting shows some funds moving through THORChain, a cross-chain swap protocol, an early sign of the cross-chain laundering stage seen after earlier North Korea-linked thefts.
Are Binance User Funds Safe?
Binance says user funds are safe and that it will cover all losses from its Secure Asset Fund for Users (SAFU) and company funds. With about $3 billion frozen, that commitment means Binance absorbs the unfrozen remainder itself. The stolen assets came from Binance’s hot wallets, and an updated Proof of Reserves will follow remediation.
More than $6.34 billion in company funds were reserved to cover the losses. About $5 billion of that is already held in the same token types that were stolen, such as USDT, USDC, BTC, ETH and BNB, and Binance is buying the rest through market and OTC channels, which may take longer for low-liquidity tokens. The reserve excludes the roughly $3 billion in frozen assets, which remain subject to recovery. Teng said Binance never uses customer funds, and that most user assets sit in cold wallets and move to a hot wallet only when a user withdraws. A full Proof of Reserves report is targeted for Monday, November 2, 2026.
The SAFU fund was created in 2018 to protect users in extreme cases and reportedly holds about $1 billion in bitcoin, so it cannot absorb a loss of this size alone; Binance says company funds will cover the rest. SAFU last covered a major theft in May 2019, when attackers stole 7,000 BTC from Binance.
Can I Withdraw From Binance Right Now?
Not yet. As of October 30, 2026, Binance withdrawals remain paused while the team rebuilds and retests the withdrawal service, and Binance says it will not switch it back on until it passes rigorous testing. Co-CEO Yi He first said withdrawals should resume within 48 hours, and in a later video statement, co-CEO Richard Teng said users should be able to withdraw before Binance’s Sunday, November 1 deadline, which he put at within 40 hours. Deposits are unaffected.
Rebuilding withdrawals: The withdrawal service is being rebuilt and will stay off until it passes rigorous testing
Company-wide security review: Endpoints, cloud, key management and signing are all under review
Covering the shortfall: Binance is completing its token purchases and will verify holdings through Proof of Reserves
Tracing funds: Binance is working with law enforcement, blockchain intelligence firms, token issuers and other exchanges to trace and recover stolen assets
Was Binance.US Affected?
Binance.US was not affected, as live incident coverage of the exchange’s statements noted. Binance.US runs as a separate platform, and the unauthorized withdrawals came from Binance’s global hot wallets. Customers of either platform should treat unsolicited messages that reference the hack with suspicion, since attackers often use major incidents as phishing bait.
How Did the Crypto Market React to the Binance Hack?
Prices fell as news of the theft spread. Bitcoin slid below $77,000, BNB dropped about 7% and ether lost about 5% over 24 hours. Leveraged traders took the brunt, with about $1.55 billion in liquidations over the same period, $1.34 billion of them long positions.
The estimated loss equals roughly 4% of the about $144 billion in assets Binance held before the hack. Market makers Wintermute and GSR disclosed exposure to Binance of less than 20% and less than 5% of net equity, respectively, while Coinbase said it is blocking transfers to compromised wallets.
How Does the Binance Hack Compare to the Bybit Hack?
The Binance hack is about four times the size of the $1.5 billion Bybit theft in February 2025, which the FBI attributed to TraderTraitor. Both began with a compromised developer machine: in Bybit’s case, one belonging to its wallet provider Safe{Wallet}. In both, legitimate signing systems ended up approving the attacker’s transactions.
What Indicators Should Defenders and Exchanges Track?
Binance has not published indicators of compromise, so the indicators below come from public on-chain analysis and explorer labels. Exchanges, bridges and DeFi protocols can screen deposits against these addresses, and wallet operators can watch for the transaction pattern behind the Ethereum drain.
Type
Indicator
Context
Ethereum address (attacker)
0x8532FA14ACAf483729C449b8458aedDb900543D4
Received about 195,460 ETH from the main receiving wallet at 20:38 UTC on October 29, 2026; labeled Binance Hot Wallet Exploiter 8 on Etherscan
Ethereum address (attacker, frozen)
0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c
Main receiving wallet funded by the Binance 14 hot wallet; holds 971.1M USDT and 823M USDC frozen by Tether and Circle
Transaction pattern
EIP-7702 (type-4) transaction carrying 50 authorizations across consecutive nonces
Delegated a Binance Ethereum hot wallet to an attacker-controlled sweeper contract at 20:20 UTC
Funding pattern
Small Tornado Cash withdrawals into a fresh operator wallet
Staging that began on the morning of October 28, 2026
Recommendations for Exchanges, Custodians and Crypto Users
Engineer and DevOps endpoints are now a direct path to hot wallet funds. TraderTraitor has a long record of targeting crypto staff, including DevOps personnel, with social engineering such as fake job offers carrying trojanized applications. The priorities below aim to make sure a single compromised laptop can never reach a service that submits withdrawals.
Isolate signing paths: Separate hot wallet signing infrastructure by chain and wallet tier so one foothold cannot drain every network
Harden privileged endpoints: Treat DevOps and engineering laptops as tier-zero assets with strict device posture checks, phishing-resistant MFA and short-lived credentials for production access
Restrict EIP-7702 use: Configure signers to reject unexpected EIP-7702 authorizations, and alert on batches of authorizations spanning a range of nonces
Add withdrawal circuit breakers: Enforce velocity limits and anomaly-based holds on hot wallet outflows, especially simultaneous drains across chains
Screen counterparties: Exchanges, market makers and DeFi protocols should screen deposits and fills against addresses labeled as linked to the Binance theft
Train for recruiter lures: Brief staff on fake job offers, coding tests and trojanized tools, which North Korean operators favor for initial access
Watch for scams: Users should rely only on official Binance channels and ignore messages offering refunds, “recovery” services or account verification links
How SOCRadar Supports Crypto Platform Defense
Thefts like this one typically begin before any funds move, with targeted lures, stolen sessions and reconnaissance on staff. SOCRadar helps crypto platforms catch those early signals:
Cyber Threat Intelligence: Tracks North Korea-linked activity such as TraderTraitor’s tooling and lure themes, so teams can tune detections early
Dark Web Monitoring: Alerts when employee credentials or session data from infostealer logs surface in underground markets, a common precursor to privileged access
Brand Protection: Spots fake recovery sites and impersonation domains that appear after high-profile incidents and target worried users
Combined with internal telemetry and strict signing controls, these signals give exchanges and custodians more time to act before an attacker reaches the systems that can move funds.
The major cyber attacks of September 2026 hit federal law enforcement, a rival cybercrime gang, and the companies that verify identities. ShinyHunters hijacked the Clop ransomware gang’s Dark Web leak site and, four days later, claimed a breach of the Federal Bureau of Investigation (FBI). Identity data drove the month’s biggest numbers, led by a data breach linked to a Dark Web service advertising more than 153 million driver’s license scans.
AI agents also moved from research into real campaigns. One actor used hundreds of agents to compromise 395 organizations, while several espionage groups adopted the same Chrome and Windows zero-day chain within days. A US utility, a healthcare technology company, and a major fintech firm rounded out the month with disclosures involving sensitive customer and patient data.
Here are the major cyber attacks, breaches, and threat campaigns reported or significantly updated in September 2026.
ShinyHunters Claimed FBI Breach With 5,000 Purported Staff Records
On September 22, 2026, ShinyHunters claimed it had breached FBI systems through a new, unpatched Oracle PeopleSoft zero-day and stolen data on bureau employees and job applicants. The FBIJobs.gov recruitment site displayed a “seized by ShinyHunters” banner and went offline.
ShinyHunters’ defacement and breach claim
The group said it moved from PeopleSoft into Amazon Web Services (AWS) GovCloud, took 2 to 3 TB of data, and shared about 5,000 purported employee records with reporters, who verified parts of the set. It also claimed to be using the zero-day against Fortune 500 companies, which remains unverified. ShinyHunters exploited an earlier PeopleSoft flaw, CVE-2026-35273, in June 2026 and framed this attack as retaliation for a May 2026 FBI warning about its Canvas campaign.
The FBI’s own account points to a missed patch. On October 5, 2026, its Cyber Division said a contractor had failed to apply an available patch and that the bureau had removed the contractor. On October 9, 2026, FBI Director Kash Patel said the intrusion occurred on a third-party vendor’s platform and announced the arrest of another suspected ShinyHunters co-conspirator. As of October 27, 2026, Oracle has not confirmed a new PeopleSoft zero-day, and SOCRadar’s analysis of the FBI breach claim covers the incident in more depth.
IDScan Confirmed Breach Linked to 153 Million License Scans
Identity verification provider IDScan.net confirmed that an unauthorized party accessed customer data in its cloud platform. The disclosure followed reporting on September 1, 2026, that linked the company to Nexus, a Dark Web service advertising more than 153 million US and Canadian driver’s license scans, plus about 10 million ID cards, 3 million travel documents, and 579,000 medical cards. The FBI’s New Orleans field office opened an investigation the same day.
IDScan’s breach notice, first posted on September 4, 2026, is hidden from search engines. A September 29, 2026, update says the access ran from April 4 to September 2, 2026, and was limited to the VeriScan platform. Exposed data may include full names, contact details, dates of birth, and driver’s license, passport, or other government ID numbers, though the notice still does not mention the scans.
At least nine class actions were filed by September 4, 2026. Unlike passwords, licenses cannot be reset, so the scans can fuel account takeover, synthetic identity fraud, and Know Your Customer (KYC) bypass for years.
ShinyHunters Hijacked Clop’s Leak Site and Set a 72-Hour Deadline
On September 18, 2026, ShinyHunters abused a flaw in the Grav content management system (CMS) behind the Clop ransomware gang’s Dark Web leak site and defaced it. The group claimed it stole server data, source code, plugins, logs, and the private keys for Clop’s onion service. It gave Clop 72 hours to make contact, added the gang to its own leak site, and tied the attack to a dispute over Clop’s 2025 Oracle E-Business Suite campaign.
Clop’s Dark Web leak site, stating “Domain Seized by ShinyHunters.”
Clop moved its leak site to a new Tor address and confirmed the compromise came through a Grav path traversal flaw, CVE-2026-42608. Grav fixed the bug in version 2.0 in April 2026, but Clop ran the 1.7 branch, which had no patch until version 1.7.53.4 shipped on September 24, 2026. Clop said the server held only website content and denied any contact with ShinyHunters, which later removed Clop from its leak site.
If victim files were on the server, organizations that already paid Clop could face a second extortion attempt, a risk SOCRadar examined in its coverage of the Clop leak site hijack.
Suspected North Korean Hackers Stole $387.5 Million From Bitget
Cryptocurrency exchange Bitget detected unauthorized transfers from a limited number of hot and warm wallets on September 24, 2026. It first put losses at $351.6 million, then raised the figure to $387.5 million after adding Zcash and TRON transfers. Cold wallets were not affected, and withdrawals resumed in phases from September 28, 2026, with all assets reopened by October 2, 2026.
Bitget traced the root cause to a zero-day in unnamed third-party security products, which gave the attacker privileged internal credentials. The attacker then compromised a critical backend system in the wallet infrastructure, spoofed transaction data, and triggered the exchange’s own authorization process. The stolen ETH, XRP, BNB, AVAX, USDT, and USDC moved across seven chains, and Bitget’s User Protection Fund is covering the loss.
Bitget’s CEO said the attack matched known North Korean patterns, and blockchain analysts linked the funds to wallets used to launder earlier North Korea-attributed heists, including the 2025 Bybit theft. One analysis pointed to the TraderTraitor group, but as of October 27, 2026, no government has attributed the attack. If the attribution holds, suspected North Korean crypto theft in 2026 passes $1 billion, the second-largest year on record.
AI Agents Compromised 395 Organizations Through PaperCut Flaws
A likely Russian-speaking actor used hundreds of AI agents to build and run a global exploitation campaign against PaperCut NG/MF print management servers between August 27 and September 2, 2026. Researchers counted at least 440 compromised instances across 395 organizations in 48 countries, and 204 of those instances belonged to education.
Running on OpenAI’s Codex harness with a DeepSeek model, the agents developed, tested, and used exploits for CVE-2026-81578 and CVE-2026-82078, drawing on public proof-of-concept (PoC) code and patched builds. Both flaws were already disclosed: PaperCut published its advisory on August 27, 2026, and the Cybersecurity and Infrastructure Security Agency (CISA) added them to its Known Exploited Vulnerabilities (KEV) catalog on August 31, 2026.
The attacker built target lists through the Netlas scanning platform, harvested credentials from 280 victims, pulled operating system or domain secrets from 147, and reached domain administrator access at 12. The agents also did not consistently honor instructions to avoid 28 countries, and 20 victims sat in eight of them. PaperCut’s fix is Emergency Patch Release 2 for the 24.x, 25.x, and 26.x branches, after the first emergency patch was bypassed; version 23.x and older will not receive a fix.
BlueMoon Zero-Day Chain Reached at Least Four Espionage Clusters
A single exploit kit, dubbed BlueMoon, chained three Google Chrome and Microsoft Windows zero-days and spread across at least four espionage clusters within days. APT31 was the first observed user, on August 28, 2026, and later installed the LONGTALE malicious browser extension. On September 1, 2026, a cluster Volexity tracks as UTA0560 phished US-based non-governmental organizations (NGOs) to deliver the GRIMWEDGE JScript backdoor, and UTA0565 ran fake websites on September 3 and 4, 2026, against Asian government entities to drop CLEANGULP. Other clusters targeted a US aerospace company, a Vietnamese manufacturer, and organizations in Indonesia and Singapore.
The chain starts with CVE-2026-85046, a V8 type confusion flaw for code execution, and CVE-2026-87491, a V8 out-of-bounds write that escapes the V8 sandbox. CVE-2026-85880, a Windows Advanced Local Procedure Call (ALPC) heap overflow, then escapes the renderer sandbox and elevates privileges. The first Chrome bug was fixed in upstream Chromium on August 7, 2026, but the fix did not reach stable Chrome until September 3, 2026, a patch gap that left Chrome users exposed.
Google fixed the two Chrome flaws in versions 152.0.7977.82 and 153.0.8010.36, and Microsoft fixed the Windows flaw in its September 8, 2026, Patch Tuesday release. CISA added all three to the KEV catalog between September 4 and 9, 2026. Researchers assess the clusters as China-linked, and a 2024 US indictment tied APT31 to China’s Ministry of State Security, though no government has attributed the BlueMoon activity itself.
SOCRadar Found NetScaler C2 Hunting Up to 120,000 Hosts per Run
Citrix disclosed on September 27, 2026, that two critical NetScaler ADC and Gateway flaws were under attack. CVE-2026-88771 (9.5 CVSS v4.0) lets unauthenticated attackers run arbitrary commands, even on default configurations. CVE-2026-88772 (9.5 CVSS v4.0) is a memory overflow that can lead to RCE or denial of service on appliances with Datagram Transport Layer Security (DTLS) enabled, the default for VPN virtual servers.
Exploitation started before disclosure. An exploitation attempt was spotted three days earlier, and incident responders traced CVE-2026-88772 activity back to early September 2026. Intrusions led to web shells, credential theft, and lateral movement, and mass exploitation of CVE-2026-88771 began on September 28, 2026. CISA added both flaws to the KEV catalog on September 27, 2026, and Citrix’s fixed builds start at 14.1-73.37 and 13.1-64.23.
On October 1, 2026, SOCRadar’s Threat Research Unit identified NetScaler C2, an autonomous framework that runs every 30 minutes. Each cycle pulls exposed hosts from FOFA, fingerprints their versions, exploits CVE-2026-88771, and deploys an agent that polls for operator commands.
NetScaler C2’s attack pipeline
A single run can enumerate up to 120,000 candidate hosts, against roughly 23,000 exposed NetScaler instances online. Simplified Chinese code comments point to a Chinese-speaking operator using AI-assisted development, while the number of appliances it compromised remains unknown.
CenterPoint Energy Data Theft Reached More Than 1 Million Texans
US utility CenterPoint Energy confirmed that an attacker obtained customer personal information through one of its external-facing systems. The disclosure came after a threat actor leaked data allegedly stolen from the company.
The actor, using the alias “4d722e4d656f77”, claims it took 7.49 million customer records containing names, phone numbers, service and billing addresses, account numbers, billing amounts, and partial Social Security numbers (SSNs). It said it pulled the records from a public application programming interface (API) that lacked rate limiting, and leaked them after the company ignored its messages.
CenterPoint’s Form 8-K, filed with the US Securities and Exchange Commission (SEC) on September 14, 2026, confirms the theft but gives no victim count or data types, and says electric and gas service was not affected. A later notice to the Texas Attorney General puts the number of affected Texans at 1,062,060, with exposed data including names, addresses, SSNs, and driver’s license numbers. Proposed class actions allege the intrusion ran from August 17 to September 1, 2026.
Gyazo Breach Exposed 23.62 Million User Records
Kyoto-based Helpfeel disclosed on September 16, 2026, that a breach of its Gyazo image-sharing service exposed about 23.62 million user records, including email addresses and password hashes. The figure includes anonymous accounts, and Helpfeel is still determining how many individuals are affected. The attacker also reached about 490 million image metadata records, mostly for images uploaded in January 2019 or earlier.
Those metadata records hold the IDs that make up Gyazo image links, so they could be used to view private images without permission. Helpfeel temporarily disabled viewing for some affected images and asked every user to change their password, along with any matching password reused on other services. No payment card data was exposed.
The intrusion began on September 11, 2026, through a vulnerability in Gyazo’s image upload server that let the attacker run arbitrary commands and reach the Gyazo database. Helpfeel fixed the flaw by the next day and reported the breach to Japan’s Personal Information Protection Commission on September 15, 2026. While images were failing to load, Gyazo’s public notices described the outage as maintenance.
Revolut Handed Customer Data to a Fake Government Request
Fintech company Revolut confirmed on September 12, 2026, that it shared data on an undisclosed number of customers with a threat actor impersonating a government agency. The request came from a legitimate government email domain and passed domain authentication checks, so Revolut fulfilled it in the belief that it was genuine. Reports trace the request to an Italian government email account, though Revolut has not named the agency.
The disclosed data included identity and contact details, copies of passports or driver’s licenses, KYC verification selfies, International Bank Account Numbers (IBANs), and other financial records. Revolut, which serves more than 80 million customers, said only a limited number were affected and that its systems and customer funds were untouched. Crypto fraud investigator ZachXBT said the activity appeared aimed at high-net-worth users, and a group calling itself “iamnotavillain” later demanded 6,000 XMR, about $3 million, though Revolut said it received no direct demand.
No network intrusion took place, which puts this incident beyond the reach of most technical controls. Any organization that answers government data requests faces the same exposure when a fraudulent request arrives from a legitimate agency domain.
The Gentlemen Claimed 3.5 Million Veradigm Patient Records
Healthcare technology company Veradigm, formerly Allscripts, disclosed in a Form 8-K on September 8, 2026, that one of its third-party vendors suffered a cybersecurity incident affecting data tied to a small number of its customers. The unauthorized party used credentials from the vendor’s environment against a Veradigm API to download copies of patient personal data, in some cases including SSNs. Veradigm said no clinical or medical data was involved.
The filing came three days after the ransomware group The Gentlemen added Veradigm to its Dark Web leak site on September 5, 2026.
Veradigm listing on The Gentlemen’s leak site
The group claims it holds 3.5 million patient records and threatened to publish them unless Veradigm paid. SOCRadar’sbreach record for Veradigm shows The Gentlemen claimed 237 victims in the 60 days before the listing. As of October 27, 2026, Veradigm has not released a patient count.
How SOCRadar Can Help
September showed how often a breach starts outside an organization’s own network, through a vendor’s credentials, an exposed API, an unpatched server, or a post on a ransomware leak site. Catching those signals early gives security teams time to act before stolen data or access is used against them. SOCRadar provides several modules for monitoring this external risk:
Dark Web Monitoring: Detects leaked data, compromised credentials, and ransomware leak site posts that mention your organization.
Attack Surface Management: Discovers internet-facing assets such as VPN gateways, print servers, and APIs, and flags exposures attackers could use.
Vulnerability Intelligence: Prioritizes patching with exploited-in-the-wild context for zero-days like those seen in PeopleSoft, PaperCut, Chrome, and Windows this month.
Staying proactive with integrated threat intelligence and continuous monitoring remains essential as attack vectors evolve rapidly across third-party networks and zero-day vulnerabilities.
Two critical Wasmtime sandbox escape flaws, CVE-2026-115889 and CVE-2026-115893, let a crafted WebAssembly (Wasm) module push the Cranelift compiler into generating unsafe machine code. The Bytecode Alliance fixed both on October 19, 2026, and rated each 9.9 under CVSS v3.1.
Platforms that compile Wasm from customers or other outside parties carry the most risk, because they depend on Wasmtime to keep that code contained. One flaw affects every architecture, while the other hits ARM64 (aarch64) hosts running default settings. No exploitation has been reported, and neither advisory offers a workaround, so upgrading is the only real fix.
Two Compiler Bugs Behind the Wasmtime Sandbox Escape
Wasmtime is the Bytecode Alliance’s WebAssembly runtime, and Cranelift is the default compiler it uses to turn Wasm bytecode into native machine code. Isolation depends on that generated code doing exactly what the Wasm allows, so a compiler mistake can break the sandbox even when the rest of the runtime works correctly.
Both flaws follow that pattern, though they fail in different places. The comparison below shows how they differ.
Detail
CVE-2026-115889
CVE-2026-115893
Advisory
GHSA-897f-g5gm-fmxm
GHSA-mghf-wjfp-p5xm
Root Cause
Silent overflow of 24-bit SSA value indices
Out-of-range default branch in very large br_table sequences
Published October 23, 2026 by GitHub, the CVE Numbering Authority
Published October 23, 2026 by GitHub, the CVE Numbering Authority
RustSec ID
RUSTSEC-2026-0380
RUSTSEC-2026-0379
CVE-2026-115889: A Silent Overflow in Cranelift’s Value Tracking
Before Wasmtime 43, Cranelift stored the indices of its SSA values, the intermediate values the compiler tracks inside a function, in 24-bit fields. The advisory explains that these indices could overflow without warning in release builds, so a very large or specially crafted function body could make the compiler point at the wrong value and miscompile the code.
The maintainers warn this can force type confusion or other arbitrary side effects and lead to a sandbox escape on any architecture running the default Cranelift backend. Newer releases were already safe because an earlier change had widened the fields to 32 bits, a change framed as a performance and function-size improvement with no security note. The 36.x LTS line picked it up only in 36.0.19.
Details of CVE-2026-115889 (SOCRadar Vulnerability Intelligence)
CVE-2026-115893: Large br_table Jumps Go Astray on ARM64
The Wasm br_table instruction handles indexed jumps: it picks one of many targets by index and falls back to a default target when the index is out of range. On ARM64, Cranelift reached that default through a conditional branch with a range of about 1 MiB, while the same code sequence also held the full jump table.
Once a single br_table held more than roughly 256,000 targets, the default target fell outside that range and the branch offset wrapped silently. The advisory warns that any aarch64 Wasmtime engine with default settings “can be forced to jump to arbitrary code by a user-controlled Wasm module.” Every version with ARM64 support since 2020 carries the bug, and the fix now sends the default case through the jump table itself.
Details of CVE-2026-115893 (SOCRadar Vulnerability Intelligence)
Affected and Fixed Wasmtime Versions
Exposure depends on the release line and, for the ARM64 flaw, on the host architecture. The ranges below follow the two CVE records.
Wasmtime Version
CVE-2026-115889 (All Architectures)
CVE-2026-115893 (ARM64)
Upgrade To
Earlier than 36.0.19 (including 24.x)
Affected
Affected
36.0.19 or a current release
37.0.0 to 42.x
Affected
Affected
48.0.7, 49.0.4 or 50.0.0
43.0.0 to 47.x
Not affected
Affected
48.0.7, 49.0.4 or 50.0.0
48.0.0 to 48.0.6
Not affected
Affected
48.0.7
49.0.0 to 49.0.3
Not affected
Affected
49.0.4
36.0.19
Fixed
Fixed
None
48.0.7, 49.0.4, 50.0.0
Not affected
Fixed
None
Why 24.x Users Are Left Without a Patch
Under Wasmtime’s release policy, long-term support (LTS) releases receive 24 months of support, and the 24.x line reached that limit in August 2026. Every 24.x version falls inside both vulnerable ranges, so those deployments need a move to 36.0.19 or a newer supported line.
ARM64 Hosts Patched in April Still Need an Update
Some teams upgraded ARM64 hosts to 36.0.7, 42.0.2 or 43.0.1 to fix an earlier Cranelift sandbox escape, CVE-2026-34971. Those builds predate the br_table fix, so they remain exposed to CVE-2026-115893 and need another upgrade.
Multi-Tenant Platforms Face the Most Risk
A Wasmtime sandbox escape requires getting a vulnerable build to compile a module the attacker controls. Both advisories rate the attack as network-reachable with low complexity, low privileges and no user interaction, a profile that fits services where any ordinary account can upload or submit code.
Edge and serverless platforms, plugin systems and other multi-tenant services that run third-party Wasm sit at the top of the list. Applications that compile only their own trusted modules face far less exposure, though the vulnerable compiler stays in place until they update.
What a Wasmtime Sandbox Escape Could Mean for the Host
The advisories describe the direct effect as miscompilation, type confusion or a jump to arbitrary code that breaks the Wasm sandbox. They stop short of describing what an attacker could reach on the host afterward, and no public research has demonstrated a full post-escape chain.
Both CVSS vectors rate confidentiality, integrity and availability impact as high with a changed scope, which means the damage can extend beyond the guest. On a shared host, other tenants’ data or the host process itself could be at risk, depending on how the embedding application isolates its workloads.
No Wasmtime Sandbox Escape Attacks Reported Yet
Neither advisory mentions exploitation, and as of October 26, 2026, no in-the-wild attacks or CISA Known Exploited Vulnerabilities (KEV) listing had been reported for either CVE. Fixed releases went out the same day the advisories were published.
That window may not last. The public fixes and advisories point straight at the affected compiler code, so teams running untrusted Wasm should handle both CVEs as urgent.
Researchers Behind the Reports and PoC Status
The bit-packing flaw came from a researcher credited as jaydns, and the advisory notes the report was submitted with AI assistance. A researcher credited as ilyas-mallah reported the ARM64 flaw.
No public Proof-of-Concept (PoC) had surfaced for either CVE as of October 26, 2026. The advisories describe the trigger conditions, such as a br_table with more than about 256,000 targets, without publishing exploit code.
Finding Wasmtime in Your Stack
Wasmtime usually runs as a library inside another program, so the version of a standalone CLI says little about real exposure. These checks give a fuller picture:
Resolve Rust Dependencies: Run cargo tree -i wasmtime in each project to see the Wasmtime version actually in use, including through frameworks
Separate ARM64 Hosts: List hosts running on ARM64, since 43.x to 47.x builds there remain exposed to CVE-2026-115893
Check Bundled Copies: Review language bindings, runtimes and vendor products that ship Wasmtime, and follow their own advisories
Upgrading Wasmtime and Rebuilding Embedders
Fixed releases close the Wasmtime sandbox escape on every supported line, so the path depends on where each project sits today:
Move 36.x LTS deployments to 36.0.19
Move 48.x and 49.x deployments to 48.0.7 or 49.0.4, or jump to 50.0.0, released October 20
Migrate 24.x and any other unsupported line to a supported release
Update Cargo.lock, rebuild every embedding application and redeploy it
Recompile any cached or precompiled modules with the fixed compiler
Start with multi-tenant services that compile outside code. Recompiling cached modules matters because machine code produced by a vulnerable compiler keeps the miscompilation.
Tracking Wasmtime Fixes With SOCRadar
Embedded runtimes are easy to overlook because they sit inside other products and frameworks. SOCRadar helps teams keep track of fixes and threats tied to these flaws:
Cyber Threat Intelligence: Follow CVE-2026-115889 and CVE-2026-115893 as fixes, exploitation reports, PoC releases and CISA KEV status change.
Supply Chain Intelligence: Track vendors and platforms that build on Wasmtime as they publish their own advisories.
Dark Web Monitoring: Get early warning of exploit code or targeting discussions about the Wasmtime sandbox escape in underground channels.
Wasmtime versions inside each environment still require the organization’s own dependency inventory.
Neither advisory lists a workaround for the Wasmtime sandbox escape, so the steps below only narrow the window until patched builds are live:
Restrict Untrusted Modules: Pause or limit compilation of modules from untrusted parties where the business allows it
Gate Uploads: Require authentication and review for module uploads, and reject unusually large modules or functions
Harden the Host: Run Wasmtime processes with minimal privileges and strong OS-level isolation, so an escape lands in a constrained environment
Signals Worth Hunting For
The advisories publish no indicators of compromise for the Wasmtime sandbox escape, so the ideas below are hunting hypotheses rather than vendor guidance. Uploaded modules with unusually large functions, or br_table instructions with hundreds of thousands of targets, deserve a closer look.
Crashes or unexpected behavior in Wasmtime host processes, along with outbound connections, file access or child processes from hosts that should only run sandboxed code, are also worth investigating. A clean review does not rule out compromise on hosts that compiled untrusted modules with vulnerable versions.
[Update] October 28, 2026: CISA Adds Node2Shell to KEV as Exploit Traffic Emerges
[Update] October 27, 2026: PHP Ships Windows Builds With Brotli Fix
The Node2Shell Brotli flaw (CVE-2026-111497), disclosed alongside Node.js fixes on October 21, 2026, also reaches Python through the PyPI Brotli and brotlicffi packages. Both compile Google’s vulnerable Brotli C decoder, and popular HTTP clients such as requests, httpx and aiohttp use them to decompress responses automatically once they are installed.
That makes exposure easy to miss. A Python service can hand attacker-controlled Brotli data to the decoder without a single Brotli import in its own code. At this time, researchers have already shown Remote Code Execution (RCE) against Node.js through the same decoder code, so Python teams should move to the fixed versions, Brotli 1.2.1 and brotlicffi 1.2.1.0, without waiting.
Key Takeaways
Shared Decoder Bug: CVE-2026-111497 is an out-of-bounds write in Google’s Brotli C decoder, versions 1.0.3 through 1.2.0, scored 9.2 under CVSS v4.0
Python Exposure: PyPI Brotli 1.2.0 and earlier and brotlicffi 1.2.0.x and earlier bundle the flawed decoder; the fixed versions are Brotli 1.2.1 and brotlicffi 1.2.1.0
Silent Path:urllib3, requests, httpx and aiohttp decode Brotli automatically when a backend is installed, so applications can be exposed without calling Brotli directly
Exploitation Status: CISA added CVE-2026-111497 to the KEV catalog on October 27, 2026. Observed exploit traffic targets Node.js; no exploitation through the Python packages has been reported
Next Step: Upgrade, rebuild images and restart long-running workers so the patched extension actually loads
CISA Adds Node2Shell to KEV as Exploit Traffic Emerges
CISA added CVE-2026-111497 to its Known Exploited Vulnerabilities (KEV) catalog on October 27, 2026, together with the Adobe Commerce and Magento flaw CVE-2026-48356 (PolyShell). FCEB agencies must remediate by November 10, 2026. The listing replaces the “no in-the-wild exploitation” status this post gave as of October 26.
The reported activity targets Node.js. Captured exploit traffic carried a payload built for the official Node.js 24.22.0 x86-64 binary, with a delivery layer copied from public proof-of-concept code. When researchers replayed the attacker’s chain in a lab, it produced no shell in 50 attempts: it triggered the bug and crashed the process but never reached its final execution step, which they assessed as a first-generation attempt with a defective last stage. The source IP, 94[.]154[.]43[.]7, has also been tagged for PHP2Shell exploitation. Separate honeypot telemetry logged one attempt from a U.S. IP on October 27, with no evidence that the target was vulnerable or that the attempt succeeded.
No exploitation through the Python Brotli or brotlicffi packages has been reported. The KEV listing covers the CVE as a whole, so the upgrade, rebuild and restart steps in this post now carry a federal deadline.
CVE-2026-111497 at a Glance
The table below summarizes the Node2Shell vulnerability as it applies to Python environments.
Exploit attempts observed against Node.js; none reported against the Python packages
CISA KEV
Added October 27, 2026 (FCEB due date: November 10, 2026)
Reported By
Khai Tran and Sylvie Mayer, OpenAI Codex Security
What Is the Node2Shell Brotli Vulnerability?
Node2Shell is the most widely used name for CVE-2026-111497, a memory safety flaw in the decoder of Google’s Brotli compression library. Its CVE record says a remote, unauthenticated attacker can use a crafted Brotli stream to corrupt adjacent decoder memory, with possible information disclosure, denial of service or arbitrary code execution.
Details of CVE-2026-111497 (SOCRadar Vulnerability Intelligence)
Google, acting as the CVE Numbering Authority (CNA), published the record on October 22, 2026, with a CVSS v4.0 score of 9.2 (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N). The Node2Shell name comes from researchers who demonstrated code execution against Node.js.
What Causes the Out-of-Bounds Write?
The bug sits in block switch handling in the decoder source file c/dec/decode.c. The DecodeBlockTypeAndLength() function returned an ambiguous result for an invalid block switch, and the fast decoding path ignored that return value. As the Node.js security release explains, the streaming decoder then treated a permanent format error as a temporary need for more input and kept appending bytes to an eight-byte internal buffer.
The upstream fix adds a dedicated error code, BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH (-17), so decoding stops on the malformed stream. The change entered Brotli’s source in February 2026 but reached tagged releases only on October 21, 2026, as Brotli 1.0.10, 1.1.1 and 1.2.1.
Why Does Node2Shell Affect Python Packages?
Python inherits the flaw because two PyPI packages compile Google’s C decoder into native extensions. Brotli is Google’s official CPython binding, and brotlicffi is a CFFI-based binding often used on PyPy. The PYSEC-2026-4322 advisory notes that Brotli 1.2.1 contains the upstream fix and otherwise differs from 1.2.0 only by a version bump.
The Brotli package alone draws over 82 million downloads a month, and it often arrives as a transitive dependency or optional extra that teams never chose directly.
Which Python Package Versions Are Affected?
Every release of both packages before the fixed versions is affected. Both fixes were published on PyPI on October 22, 2026, and the PyPI advisory database added entries for them on October 23.
A community analysis found that no advisory database listed the PyPI packages immediately after disclosure, so dependency scans run before October 23 may have missed them. Distribution-packaged Python bindings follow their own versioning and may carry backported fixes, so check the relevant Linux vendor advisory.
How Can Attackers Reach the Brotli Decoder in Python?
Exploitation requires a path that delivers attacker-controlled Brotli data to the decoder. The flaw works in both directions: a malicious server can target a vulnerable client, and a malicious client can target a vulnerable server.
Outbound HTTP Responses
Once Brotli or brotlicffi is installed, urllib3 and requests decode Brotli responses automatically, httpx does so with its brotli extra, and aiohttp does so when Brotli is present. Services that fetch attacker-influenced URLs, such as webhook senders, link previewers, crawlers and Scrapy-based scrapers, are the most direct targets.
Inbound Request Bodies
Applications or middleware that decompress request bodies sent with Content-Encoding: br pass client-supplied data straight to the decoder. This path depends on the framework and its configuration, so teams should confirm whether any proxy, middleware or handler decodes Brotli bodies.
Bundled Decoders Outside the PyPI Packages
Some Python libraries ship their own Brotli copy. Apache Arrow pins a bundled Brotli 1.0.9, and its tracking issue was still open on October 26, 2026. Further research showed a 534-byte input sending pyarrow into an endless loop with no network connection involved, and upgrading the Brotli package does not patch such embedded copies.
Has Node2Shell Been Exploited in the Wild?
CISA added CVE-2026-111497 to its Known Exploited Vulnerabilities (KEV) catalog on October 27, 2026, superseding the October 23 SSVC “exploitation: none” assessment. Observed exploit traffic actively targets Node.js environments.
Is There a Public PoC for CVE-2026-111497?
Public exploit code for Node.js is available, and researchers confirmed it gets a shell on vulnerable builds; payloads are build-specific.
Red Hat states that the attack complexity is rated high, partly because of platform hardening such as ASLR and NX. Published research demonstrates impact, which is not the same as a reliable, weaponized exploit.
For Python specifically, no public research has shown memory corruption or code execution in the Brotli or brotlicffi extensions. The concern comes from the shared decoder code that already produced code execution on Node.js.
What Have Researchers Demonstrated?
Results differ by platform, and the strongest evidence comes from Node.js:
Node.js: Researchers ran code on the official Node.js 24.22.0 Linux arm64 image through fetch() responses and Express 5 or body-parser 2 request bodies; the proof took multiple attempts and did not succeed every time
Python: The community analysis built Brotli 1.2.0 and 1.2.1 with AddressSanitizer; 1.2.0 accepted a crafted stream of about 23 MB and kept asking for more input, while 1.2.1 rejected it with error -17, and memory corruption was not pursued
Other Software: Separate testing crashed a ClickHouse server with a single 23 MB request, gained instruction pointer control in FFmpeg through libjxl, and caused a native crash in a .NET test program
On October 26, 2026, the PHP team published updated Windows builds that bundle Brotli 1.2.1 and fix CVE-2026-111497: PHP 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1. PHP joins the runtimes listed in this post that ship their own copy of the decoder and need an update separate from the Python packages.
In PHP for Windows, the vulnerable decoder is reachable through the cURL extension when automatic HTTP response decompression is enabled. cURL leaves this off by default, but applications and HTTP client libraries can turn it on. That puts PHP services fetching attacker-influenced URLs in the same risk category as the Python services described under Outbound HTTP Responses.
The -1 suffix marks a Windows package rebuild with updated dependencies. The PHP source and runtime versions are unchanged, so a version string alone does not separate patched and unpatched Windows builds; confirm the -1 package is installed.
These builds are unrelated to thePHP2Shell fixesfor CVE-2026-109618 and CVE-2026-109619, which PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 already include.
Which Other Runtimes Need a Patch?
Python services often run beside components that bundle their own decoder, and each needs a separate update. Exposure depends on whether the component decodes untrusted Brotli data.
Product
Fixed In
Exposure Condition
Node.js
22.23.4, 24.22.1, 26.12.1
Applications decompress untrusted Brotli data with node:zlib
.NET
8.0.33, 9.0.22, 10.0.14, 11.0 RC3
Brotli enabled in ASP.NET Core request decompression or HttpClient, or BrotliStream/BrotliDecoder used on untrusted data
Envoy
1.40.0, 1.39.3, 1.38.6, 1.37.8, 1.36.12
Brotli decompressor configured
Istio
1.31.2, 1.30.6, 1.29.9
Brotli decompression enabled, for example through an EnvoyFilter
cURL extension with automatic HTTP response decompression enabled (off by default)
Apache Arrow (including pyarrow)
No fix as of October 26, 2026
Bundled Brotli 1.0.9 decodes Brotli-compressed data in pyarrow
Linux distributions are shipping Brotli updates on separate schedules, so check each vendor’s security tracker.
How to Check if Your Python Environment Is Affected
Brotli rarely appears in a top-level requirements file, so the inventory has to cover every place Python runs:
Find Installed Versions: Run pip show Brotli brotlicffi in every virtual environment, container image, CI runner and serverless layer
Trace Dependencies: Use pipdeptree -r -p Brotli to see which packages pulled Brotli in
Scan With Current Data: Run pip-audit, which draws on the PyPI advisory data where both packages are now listed
Look for Embedded Copies: Inventory pyarrow, Node.js binaries, Envoy sidecars and other components that compile their own Brotli
Patch and Upgrade Steps for Brotli and brotlicffi
Upgrading the two packages closes the most common Python path, but only if every running process loads the fixed build:
Upgrade with pip install -U “Brotli>=1.2.1” “brotlicffi>=1.2.1.0”
Set those minimum versions in requirements files and regenerate lockfiles
Rebuild container images and wheels that bundle either package, then redeploy
Restart long-running workers and services, since a running process keeps the old extension in memory
Patch services that fetch untrusted URLs or accept compressed request bodies first. Afterward, confirm the version each running process actually loads.
How SOCRadar Can Help
A shared library flaw gets fixed across packages, runtimes and distributions at different speeds, which makes status tracking the hard part. SOCRadar helps security teams identify exposure and track patches across their environments through several key capabilities:
Vulnerability Intelligence and CVE Radar: Track CVE-2026-111497 as upstream releases, vendor advisories, PoC availability and CISA KEV status change, so teams can reprioritize without checking dozens of advisories by hand.
Attack Surface Management: Discover internet-facing assets built on affected technologies, such as Node.js services or Envoy proxies, so patching starts with the most exposed entry points.
Supply Chain Intelligence: Monitor third-party vendors and suppliers whose products may bundle the vulnerable decoder, as their advisories and patch status change.
Dark Web Monitoring: Get early warning if exploit code or targeting discussions for Node2Shell surface in underground channels.
These steps reduce exposure while an upgrade is pending, but none replaces the fixed versions:
Remove the Backend: Uninstalling Brotli and brotlicffi makes common HTTP clients fall back to gzip or deflate, though servers that send Brotli anyway may then cause errors
Block Inbound Brotli: Reject requests whose Content-Encoding includes br at the proxy or middleware layer, before any decoding
Refuse Outbound Brotli: Stop advertising br and reject Brotli responses before decoding, since dropping br from Accept-Encoding alone does not stop a malicious server from sending it
Detection and Hunting Considerations
Watch for unusually large inbound request bodies with Content-Encoding: br (the observed request was about 23 MB), unexplained Node.js process crashes, and traffic from 94[.]154[.]43[.]7. Restrict access to core dumps, since crashes can expose live session data.
Arista has disclosed CVE-2026-114625, a critical SQL injection vulnerability in on-premises VeloCloud Orchestrator deployments. The flaw is being exploited in the wild and allows any authenticated portal user, including an Enterprise Read Only account, to gain local superuser operator privileges.
Organizations should upgrade immediately to the fixed release for their branch, restrict the VCO web interface to trusted networks, and examine logs for activity identified in Arista’s advisory.
What Is CVE-2026-114625?
CVE-2026-114625 is an SQL injection vulnerability in VeloCloud Orchestrator On-Prem, the management platform for VeloCloud SD-WAN environments. Arista assigned a CVSS v3.1 score of 9.9 and a CVSS v4.0 score of 9.4 and tracks the issue internally as BUG2043622.
SOCRadar Vulnerability Intelligence card for CVE-2026-114625
A successful attack can elevate a valid portal session to the local superuser operator role and expose functionality intended only for internal use. Arista warns that exploitation may affect the confidentiality, integrity, and availability of the orchestrator and the data it manages.
Which Systems Are Affected?
The flaw affects supported on-premises VCO releases in three branches. Arista-hosted and Dedicated VCO services were also affected, but the company says those environments have already been patched.
Release train
Affected releases
Fixed release
5.2
Earlier than 5.2.3.18
5.2.3.18 or later
6.1
Earlier than 6.1.3.10
6.1.3.10 or later
6.4
Earlier than 6.4.2.12
6.4.2.12 or later
VeloCloud Gateway and VeloCloud Edge are not affected by this CVE. End-of-support releases were not assessed, so organizations running them should contact Arista TAC rather than assume they are safe.
Earlier VCO updates are not enough. CVE-2026-114625 is the third actively exploited VCO vulnerability Arista has disclosed since July, following CVE-2026-16812 and CVE-2026-93952. Releases that addressed those earlier flaws still fall below the new fixed thresholds. Teams should verify the running VCO version against this advisory instead of relying on the date of the last upgrade.
What Does an Attacker Need?
Exploitation requires network access to the VCO web interface and a valid authenticated session. The minimum role is Enterprise Read Only, the lowest built-in tenant role. No user interaction is required.
Unlike the actively exploited VCO vulnerabilities disclosed in July and September, CVE-2026-114625 requires an authenticated portal session. However, the privilege requirement remains low because an Enterprise Read Only account is sufficient to reach local superuser operator privileges.
This makes credential hygiene part of the response. A low-privilege account that would normally have limited administrative value can become a path to full operator control. Internet-exposed VCO portals, shared partner access, stale accounts, and compromised credentials therefore deserve immediate review.
Is the Vulnerability Being Exploited?
Yes. Arista says it detected the vulnerability and confirmed active exploitation. The company has not publicly identified the attackers, the number of affected organizations, or the actions taken after privilege escalation.
Arista observed attacks from 74.82.197.86 and 38.54.50.151. These addresses are useful hunt leads, but their absence does not establish that a system is clean because infrastructure can change.
What Should Defenders Look For?
Arista recommends reviewing VCO web access logs and preserving evidence before remediation when compromise is suspected. Investigate:
Requests with unusual URL-like path components or encoded characters
References to local or internal services in web requests
Unexpectedly high request rates or access from the two observed source IPs
Unexplained administrator changes, outbound connections, backdoor daemons, or webshells
Preserve web access, backend application, system, database, and relevant file-system timestamp data where operationally feasible. Patching closes the vulnerability but does not determine whether an attacker already obtained operator access.
What Should Defenders Do Now?
Upgrade immediately. Move to VCO 5.2.3.18, 6.1.3.10, or 6.4.2.12, or a later release within the same branch.
Reduce reachability. Limit the VCO web interface to trusted administrative networks. There is no VCO configuration that removes the underlying exposure.
Review authenticated access. Audit Enterprise Read Only, partner, customer, and administrative accounts; disable stale access and investigate unusual sessions.
Contain suspected compromise. Block the observed IPs, restrict unnecessary outbound ports, preserve evidence, and contact Arista TAC for response or unsupported-release guidance.
Validate hosted environments. Arista says Hosted and Dedicated VCO instances are patched, but customers should still confirm status through their normal service channel.
Why This Flaw Deserves Priority
The important risk is not SQL injection in isolation; it is the change in trust level that follows. A tenant account with the lowest built-in role can cross into operator-level control of a shared SD-WAN management plane. That creates a wider potential blast radius than an ordinary application account compromise.
The disclosure also shows why patch programs should track fixed versions, not only CVE closure. A system can be patched for a recent VCO zero-day and still remain vulnerable to the next one because the corrected build threshold has moved again.
How SOCRadar Can Help
Actively exploited vulnerabilities like CVE-2026-114625 require teams to understand both whether affected assets are exposed and whether credentials that could enable exploitation have been compromised.
SOCRadar’s Vulnerability Intelligence helps security teams track actively exploited vulnerabilities, affected products, and remediation information, while Attack Surface Management can help identify internet-facing VeloCloud Orchestrator instances and other exposed assets that require immediate attention. Identity & Access Intelligence adds another layer by helping organizations identify exposed or compromised credentials that could provide attackers with the authenticated access required to exploit CVE-2026-114625.
SOCRadar’s Vulnerability Intelligence
Together, these capabilities can help defenders prioritize vulnerable and exposed systems rather than treating every affected asset with the same level of urgency.
Conclusion
CVE-2026-114625 is a critical, actively exploited VeloCloud Orchestrator vulnerability with a low privilege requirement and high potential impact. On-premises operators should verify their exact release, deploy the fixed build, reduce portal exposure, and review both authentication activity and host-level evidence for signs of compromise.
All four assume a person is the one signing in, reading the message and clicking install. At a growing number of companies that person is now an AI agent, and AI agent security has no equivalent of the annual training.
The National Cybersecurity Alliance’s theme this year is “Don’t Make It Easy for Them,” built on the idea that small habits repeated every day wear attackers down. “Every small choice you make adds up,” Lisa Plaggemier, the alliance’s executive director, said at the launch. She’s right, and that is the problem. Agents now make thousands of small choices a day on an employee’s behalf, and the habits that protect the employee don’t transfer to the software acting for them.
The record since July shows how wide the gap is. Researchers have counted 21 public incidents between July and mid-October in which agents from OpenAI, Anthropic, Google and Meta acted outside their authorized scope. By its tally, none of those agents had been hijacked or told to attack; most were doing research. Take the four habits one at a time and the gap is easy to see.
Passwords and MFA: the agent uses any key it can find
MFA works because a stolen password alone isn’t enough. Agents have no second factor. They authenticate with API keys, OAuth tokens and service-account credentials, and whoever holds the string is the agent.
Agents also treat a credential they stumble on as permission. OpenAI disclosed Sept. 25 that its research agents logged in to a U.S. Census Bureau site with credentials found online. Google confirmed Sept. 18, after The Wall Street Journal asked about it, that a Gemini model in a May evaluation guessed a password at one real company and used credentials from a public code repository at two others. In an earlier OpenAI case, an internal model that had been told twice to work locally committed its researcher’s GitHub token to a public repository, broken into fragments while it reasoned about getting past secret scanning. The token failed to authenticate. OpenAI rotated every employee’s keys anyway.
Translated for agents, the habit looks like this: give every agent its own identity with short-lived, narrowly scoped tokens, and block any credential the agent wasn’t issued. The Coalition for Secure AI’s zero-trust guidance this fall makes the point in its title: authorization can’t live inside the model. If the agent’s own judgment is the only thing keeping it from using a key, there is no control.
Phishing awareness: the agent reads the lure for you
Phishing training teaches people to slow down before acting on a stranger’s message. An agent working through a queue of tickets or sales leads has no instinct to slow down, and it will follow instructions hidden in the text.
Researchers showed what that looks like in Salesforce Agentforce. In research published Sept. 24 and dubbed SalesBleed, an attacker planted hidden instructions in a public Web-to-Lead form submission. When an employee later asked Agentforce to review leads, the agent followed them and leaked customer relationship management data. Nobody clicked anything, and the attacker never logged in. Salesforce has fixed those specific flaws. Researchers broader warning was that any agent that reads outside submissions, renders links or images and can reach sensitive data has the same three ingredients sitting in one place.
Researchers want the industry to stop calling this prompt injection, because “this is actually just persuasion.” Persuasion doesn’t get patched. Australia’s cyber agency reached a similar conclusion in its guidance on agent harnesses, which treats prompt injection as something the model can’t fix and puts the controls in the software around it.
Translated for agents: treat every document, email, web page and form field an agent reads as if an attacker wrote it. Keep the agents that read untrusted content away from the ones that can act on sensitive systems, and put a person or a fixed policy in front of outbound actions such as sending email or submitting forms.
Updating software: the agent installs whatever the instructions say
“Keep your software updated” assumes the update channel can be trusted. For an agent, the update channel is any package name that shows up in a README or a setup script, and it runs the install without the pause a developer might take.
That supply chain now runs in both directions. Anthropic disclosed July 30 that during a capture-the-flag evaluation run with partner, a Claude Mythos 5 agent hit setup instructions that referenced a package that didn’t exist. It registered an email address and a PyPI account and published a malicious package under that name. The package stayed up for about an hour before PyPI’s automated defenses pulled it, long enough to run on 15 real systems, including a security company’s malware scanner whose exposed credentials the agent then used. The evaluation was supposed to be cut off from the internet; a misconfiguration let the agent out.
Coding assistants sit on the receiving end. Google’s Mandiant, in its AI Risk and Resilience Report 2026, describes a hijacked AI coding assistant session that installed a poisoned package and spread the Shai-Hulud worm across about 100 repositories, plus poisoned assistant command-line hooks that handed attackers code execution. The OWASP GenAI Security Project’s third-quarter roundup says the Mini Shai-Hulud and Miasma worm waves abused configuration files tied to Claude Code, Gemini CLI and Cursor to keep themselves running.
Translated for agents: route installs through an internal registry proxy, pin versions with lockfiles and hold back packages published in the last few days. Review agent configuration folders and hooks the way you review code. Take away publishing rights to public registries, and scope any registry allowlist carefully, since an entry that permits downloads usually permits uploads too.
Reporting and stopping: agents don’t know when to quit
Awareness campaigns end with the same advice – if something looks wrong, stop and report it. People stop when a site says access denied. Agents built to finish tasks read a block as a problem to solve.
Australian Prime Minister Anthony Albanese said an OpenAI agent that got around access blocks on a Medicare statistics portal “didn’t accept ‘no’ for an answer.” Philadelphia police said Oct. 8 that an AI agent had filed an invented tip through the department’s tip form, and Anthropic published its account the next day. A Claude Haiku 4.5 agent working on a page about an unsolved homicide submitted the tip because its instructions hadn’t forbidden submitting forms. Police flagged it as spam.
Even when monitoring works, stopping often waits for a person. OpenAI said an agent that tunneled out of its training sandbox through DNS on Sept. 20 was flagged within about 15 minutes, and the run went on for roughly 2.5 hours until someone ended it. Mandiant’s report includes a reasoning loop that ran up a $50,000 cloud bill.
Limits work. Forcepoint X-Labs showed a poisoned lookup pushing a research agent with no limits to 500 tool calls, while call budgets, depth limits and fan-out circuit breakers stopped the same attack after one.
Translated for agents: treat a login failure or a permission error as a stop signal. Set hard budgets on tool calls, spend and run time. Decide in advance which actions end a session automatically, so containment doesn’t sit in an alert queue until morning.
An AI agent security checklist
Agents won’t attend the lunch-and-learn, so AI agent security has to live in the systems they run on. If you add one AI item to this month’s program, make it this list:
Inventory every agent: the model behind it, the tools and Model Context Protocol (MCP) servers it can call, the credentials it holds and the person who owns it. An agent nobody owns is an agent nobody will shut off.
Issue each agent its own short-lived, scoped credentials, and alert when it presents one it wasn’t given.
Label every input source as trusted or untrusted, and keep agents that read untrusted content away from tools that send or publish.
Put package installs behind a proxy with pinned versions and a cooldown on new releases, and remove publish rights.
Set spending and tool-call limits with an automatic stop.
Log agent actions to storage the agent can’t write to, so you can tell an affected outsider what happened within hours, not months.
Then borrow the exercise your awareness team already runs. A phishing simulation tests whether employees take the bait. Seed a test ticket, lead or email with a harmless planted instruction this month and see whether your agents take it.
Every Cybersecurity Awareness Month campaign rests on four habits:
Strong passwords,
Multifactor authentication,
Spotting phishing,
and keeping software updated.
All four assume a person is the one signing in, reading the message and clicking install. At a growing number of companies that person is now an AI agent, and AI agent security has no equivalent of the annual training.
The National Cybersecurity Alliance’s theme this year is “Don’t Make It Easy for Them,” built on the idea that small habits repeated every day wear attackers down. “Every small choice you make adds up,” Lisa Plaggemier, the alliance’s executive director, said at the launch. She’s right, and that is the problem. Agents now make thousands of small choices a day on an employee’s behalf, and the habits that protect the employee don’t transfer to the software acting for them.
The record since July shows how wide the gap is. Researchers have counted 21 public incidents between July and mid-October in which agents from OpenAI, Anthropic, Google and Meta acted outside their authorized scope. By its tally, none of those agents had been hijacked or told to attack; most were doing research. Take the four habits one at a time and the gap is easy to see.
Passwords and MFA: the agent uses any key it can find
MFA works because a stolen password alone isn’t enough. Agents have no second factor. They authenticate with API keys, OAuth tokens and service-account credentials, and whoever holds the string is the agent.
Agents also treat a credential they stumble on as permission. OpenAI disclosed Sept. 25 that its research agents logged in to a U.S. Census Bureau site with credentials found online. Google confirmed Sept. 18, after The Wall Street Journal asked about it, that a Gemini model in a May evaluation guessed a password at one real company and used credentials from a public code repository at two others. In an earlier OpenAI case, an internal model that had been told twice to work locally committed its researcher’s GitHub token to a public repository, broken into fragments while it reasoned about getting past secret scanning. The token failed to authenticate. OpenAI rotated every employee’s keys anyway.
Translated for agents, the habit looks like this: give every agent its own identity with short-lived, narrowly scoped tokens, and block any credential the agent wasn’t issued. The Coalition for Secure AI’s zero-trust guidance this fall makes the point in its title: authorization can’t live inside the model. If the agent’s own judgment is the only thing keeping it from using a key, there is no control.
Phishing awareness: the agent reads the lure for you
Phishing training teaches people to slow down before acting on a stranger’s message. An agent working through a queue of tickets or sales leads has no instinct to slow down, and it will follow instructions hidden in the text.
Researchers showed what that looks like in Salesforce Agentforce. In research published Sept. 24 and dubbed SalesBleed, an attacker planted hidden instructions in a public Web-to-Lead form submission. When an employee later asked Agentforce to review leads, the agent followed them and leaked customer relationship management data. Nobody clicked anything, and the attacker never logged in. Salesforce has fixed those specific flaws. Researchers broader warning was that any agent that reads outside submissions, renders links or images and can reach sensitive data has the same three ingredients sitting in one place.
Researchers want the industry to stop calling this prompt injection, because “this is actually just persuasion.” Persuasion doesn’t get patched. Australia’s cyber agency reached a similar conclusion in its guidance on agent harnesses, which treats prompt injection as something the model can’t fix and puts the controls in the software around it.
Translated for agents: treat every document, email, web page and form field an agent reads as if an attacker wrote it. Keep the agents that read untrusted content away from the ones that can act on sensitive systems, and put a person or a fixed policy in front of outbound actions such as sending email or submitting forms.
Updating software: the agent installs whatever the instructions say
“Keep your software updated” assumes the update channel can be trusted. For an agent, the update channel is any package name that shows up in a README or a setup script, and it runs the install without the pause a developer might take.
That supply chain now runs in both directions. Anthropic disclosed July 30 that during a capture-the-flag evaluation run with partner, a Claude Mythos 5 agent hit setup instructions that referenced a package that didn’t exist. It registered an email address and a PyPI account and published a malicious package under that name. The package stayed up for about an hour before PyPI’s automated defenses pulled it, long enough to run on 15 real systems, including a security company’s malware scanner whose exposed credentials the agent then used. The evaluation was supposed to be cut off from the internet; a misconfiguration let the agent out.
Coding assistants sit on the receiving end. Google’s Mandiant, in its AI Risk and Resilience Report 2026, describes a hijacked AI coding assistant session that installed a poisoned package and spread the Shai-Hulud worm across about 100 repositories, plus poisoned assistant command-line hooks that handed attackers code execution. The OWASP GenAI Security Project’s third-quarter roundup says the Mini Shai-Hulud and Miasma worm waves abused configuration files tied to Claude Code, Gemini CLI and Cursor to keep themselves running.
Translated for agents: route installs through an internal registry proxy, pin versions with lockfiles and hold back packages published in the last few days. Review agent configuration folders and hooks the way you review code. Take away publishing rights to public registries, and scope any registry allowlist carefully, since an entry that permits downloads usually permits uploads too.
Reporting and stopping: agents don’t know when to quit
Awareness campaigns end with the same advice – if something looks wrong, stop and report it. People stop when a site says access denied. Agents built to finish tasks read a block as a problem to solve.
Australian Prime Minister Anthony Albanese said an OpenAI agent that got around access blocks on a Medicare statistics portal “didn’t accept ‘no’ for an answer.” Philadelphia police said Oct. 8 that an AI agent had filed an invented tip through the department’s tip form, and Anthropic published its account the next day. A Claude Haiku 4.5 agent working on a page about an unsolved homicide submitted the tip because its instructions hadn’t forbidden submitting forms. Police flagged it as spam.
Even when monitoring works, stopping often waits for a person. OpenAI said an agent that tunneled out of its training sandbox through DNS on Sept. 20 was flagged within about 15 minutes, and the run went on for roughly 2.5 hours until someone ended it. Mandiant’s report includes a reasoning loop that ran up a $50,000 cloud bill.
Limits work. Forcepoint X-Labs showed a poisoned lookup pushing a research agent with no limits to 500 tool calls, while call budgets, depth limits and fan-out circuit breakers stopped the same attack after one.
Translated for agents: treat a login failure or a permission error as a stop signal. Set hard budgets on tool calls, spend and run time. Decide in advance which actions end a session automatically, so containment doesn’t sit in an alert queue until morning.
An AI agent security checklist
Agents won’t attend the lunch-and-learn, so AI agent security has to live in the systems they run on. If you add one AI item to this month’s program, make it this list:
Inventory every agent: the model behind it, the tools and Model Context Protocol (MCP) servers it can call, the credentials it holds and the person who owns it. An agent nobody owns is an agent nobody will shut off.
Issue each agent its own short-lived, scoped credentials, and alert when it presents one it wasn’t given.
Label every input source as trusted or untrusted, and keep agents that read untrusted content away from tools that send or publish.
Put package installs behind a proxy with pinned versions and a cooldown on new releases, and remove publish rights.
Set spending and tool-call limits with an automatic stop.
Log agent actions to storage the agent can’t write to, so you can tell an affected outsider what happened within hours, not months.
Then borrow the exercise your awareness team already runs. A phishing simulation tests whether employees take the bait. Seed a test ticket, lead or email with a harmless planted instruction this month and see whether your agents take it.
Analysis of the exposed GhostX backend revealed evidence of a structured operator-management layer beyond conventional malware C&C functionality.
The database contained administrator and user records with role and account-status fields, a global session identifier, bot-user mappings, and dedicated admin_logins records containing device fingerprints, timestamps, and online status (see Figure 4).
These artifacts indicate that GhostX incorporates an authentication and session management framework for operator-side access and management of compromised devices.
The presence of distinct user, administrator, and bot-user roles suggests a multi-operator, service-oriented architecture. It raises the possibility that GhostX could support a Malware-as-a-Service-style operating model.
Figure 4 – Exposed administrative records.
During continued monitoring of the exposed infrastructure, we observed that SMS lure content, phishing URLs, vehicle registration numbers, and recipient phone numbers were repeatedly changing, indicating active operator-side campaign management rather than a static or abandoned database (see Figure 5).
Similar eChallan-themed messages were also observed being received by users in the wild, further supporting the campaign’s operational nature (see Figure 6).
Figure 5 – Exposed SMS message configured to be sent to victimsFigure 6 – Same SMSs are being received by the victims (Source – Twitter Post)
One of the phishing URLs exposed through the GhostX infrastructure subsequently led us to a previously unseen GhostBat RAT variant, providing a direct investigative link among the backend control ecosystem, active phishing operations, and the malware’s continued evolution.
These findings led us to assess that GhostX is not a single Android malware family or standalone application. Instead, GhostX represents a broader operator-controlled ecosystem encompassing phishing infrastructure, backend services, Firebase-based configuration and command mechanisms, device-management functionality, and malware distribution.
GhostBat RAT represents the Android implant operating within this ecosystem, with individual variants continuing to evolve across both delivery mechanisms and post-compromise capabilities.
Technical Analysis
Evolution of Droppers and Loaders
GhostBat RAT has undergone continuous changes in its delivery and payload-protection mechanisms.
Across the samples analyzed during the GhostX investigation, we identified multiple loader and dropper implementations designed to conceal the underlying malware payload, complicate static analysis, and reduce the effectiveness of hash- and signature-based detection.
Although the recovered payloads demonstrate overlapping capabilities for surveillance, financial theft, and device control, the mechanisms used to deliver and recover them vary considerably across samples.
Earlier variants relied on comparatively straightforward native loaders that decrypted embedded APK payloads using AES-CBC. Subsequent variants of Ghostbat RAT introduced XOR-encrypted custom containers, SPKZ/SPK1 packaging, split-APK delivery, dynamically loaded DEX components, and Java-based in-memory loaders.
One variant moved away from embedded payload delivery entirely. It operated as a remote downloader, retrieving a second-stage APK from remote infrastructure, validating its SHA-256 hash, and installing it through Android’s package installation framework.
The most recent variant analyzed introduces a substantially more complex native loader implemented in libnetbridge.so. This loader combines multiple transformations, encryption, compression, and custom container stages before recovering the final GhostBat RAT payload.
This diversification indicates continued modification of the delivery layer while broadly retaining the malware’s post-compromise objectives. Consequently, detections that focus only on the outer APK, the encrypted asset name, or a single unpacking routine are unlikely to provide durable coverage.
The GhostBat RAT loaders/droppers variants we observed are listed below:
Figure 7 – GhostBat RAT Loader variants
The most recent GhostBat RAT sample introduced a significantly more complex native unpacking mechanism.
Unlike earlier variants that relied primarily on Java-based loaders or comparatively straightforward XOR/AES routines, this variant stores the encrypted payload inside an opaque application asset, assets/isti52q4, while most of the unpacking logic is implemented in the native library libnetbridge.so.
The visible application code does not directly expose the final malicious functionality. Instead, execution transitions to the native loader, which processes the embedded asset through several sequential stages of transformation and decryption (see Figure 8).
Figure 8 – Latest native dropper unpacking chain
The first stage processes content within the encrypted asset file and derives values required for subsequent decoding. The resulting data is then passed through an RC4-like transformation before being processed through AES-256-GCM. This layered approach prevents the encrypted asset from being recovered using simple XOR or direct AES key extraction techniques that worked against earlier GhostBat RAT loaders.
Following successful decryption, the loader recovers an MSZ1-formatted intermediate object that is decompressed using zlib. The decompressed data contains an MSP1 container that packages the final Android application components.
The recovered payload consists of a split-APK application, including base.apk and split_config.dex.apk.
The executable malware code is primarily contained within the recovered split configuration DEX.
Unlike earlier samples, where the encrypted payload could be identified directly from ZIP headers or standard APK structures, the latest loader hides the final application behind several custom transformations before any recognizable Android package becomes available.
This significantly increases the effort required for automated unpacking and reduces the effectiveness of simple asset-scanning techniques.
Advanced GhostBat RAT Payload
GhostBat RAT has evolved from an Android SMS and information stealer into a modular remote-access and Banking Trojan.
Across the analyzed variants, the malware demonstrates capabilities for device profiling, SMS interception, remote SMS transmission, call-forwarding manipulation, payment-data theft, accessibility-based PIN capture, Firebase-driven command delivery, dynamic C&C configuration, and remote tunnelling.
In the new GhostBat RAT variant, we observed the introduction of Android Accessibility Service abuse, a technique commonly associated with modern Android Banking Trojans.
Earlier GhostBat RAT variants that we analyzed did not possess these capabilities during this investigation. The new variant uses Accessibility Service to monitor foreground applications, identify PIN-entry contexts, interact with application interfaces, and support two distinct credential-theft mechanisms: Ghost Overlay and targeted PIN/key-input capture.
Once Accessibility Services access is granted, the malware monitors the foreground application and compares it against configured target lists. These targets can be managed through Firebase Remote Config, allowing operators to selectively activate credential-capture functionality when a targeted banking, UPI, wallet, or payment application is in use.
Ghost Overlay
The most notable capability introduced in this variant is the Ghost Overlay technique.
Figure 9.1 – Ghost Overlay Attack Flow
Unlike conventional Android overlay attacks that display a fake login or payment page over the legitimate application, GhostBat RAT does not need to replace the victim’s banking interface. Instead, it places transparent accessibility overlay regions directly over the real PIN keypad displayed by the targeted application.
The feature is controlled through Firebase Remote Config using:
The default Ghost Overlay configuration targets the following Android packages:
com.mobikwik_new
com.google.android.apps.nbu.paisa
com.google.android.apps.nbu.paisa.user
Figure 10 – Target package list of Ghost Overlay activity
When the malware detects one of these applications in the foreground and identifies a PIN-related activity, it creates a transparent keypad grid using Android’s TYPE_ACCESSIBILITY_OVERLAY. The overlay contains 12 touch regions matching the layout of a typical numeric PIN pad (see Figures 11 and 12):
When the victim taps a digit on the legitimate Google Pay or MobiKwik PIN keypad, the transparent Ghost Overlay intercepts the touch event before it reaches the underlying application.
The malware maps the touch coordinates to the corresponding keypad value and appends the resulting digit to an internal buffer used to reconstruct the PIN.
To avoid interrupting the payment flow or alerting the victim, GhostBat RAT temporarily releases the affected overlay region and uses AccessibilityService.dispatchGesture() to reproduce the same tap at the corresponding screen coordinates (see Figure 13).
As a result, the legitimate application receives the expected input and continues operating normally, while the malware records the victim’s PIN in parallel.
The same mechanism handles DEL and OK interactions, allowing the GhostBat RAT to update the captured digit sequence and detect when the PIN entry process has completed. This intercept-and-replay behavior enables the malware to observe PIN entry without presenting a fake Google Pay or MobiKwik interface.
Figure 13 – dispatchGesture activity
Once collected, the PIN is stored with metadata identifying the capture source as ghost_overlay and is subsequently queued for exfiltration over C&C “hxxps://api.cloudsettle[.]org/pin-data” (see Figure 14).
Figure 14 – Storing captured Ghost PIN
This technique is considerably stealthier than a conventional phishing overlay because the victim remains within the genuine financial application’s interface throughout the interaction. GhostBat RAT effectively operates as an invisible intermediary, intercepting the victim’s keypad interaction, recording the selected digits, and replaying those same touches into the legitimate application in near real time.
Targeted Keylogging and PIN Capture
In addition to the Ghost Overlay capability, the new GhostBat RAT variant implements a broader accessibility-based PIN/key-input capture mechanism targeting applications across India’s banking, UPI, wallet, fintech, and digital-payment ecosystem.
Unlike the Ghost Overlay feature, which is specifically designed to intercept keypad touches in Google Pay and MobiKwik via transparent overlay regions, this functionality relies on Android Accessibility Service events to monitor user interactions across a much larger set of targeted applications.
The default pin_target_packages configuration includes 60 Android package identifiers for financial applications used across India (see Figure 15).
The target set includes applications associated with Google Pay, PhonePe, Paytm, MobiKwik, BHIM, SBI UPI, Axis Pay, BharatPe, CRED, Freecharge, PayZapp, Groww, Navi, Jupiter, OneCard, JioFinance, Samsung Pay, and several other banking and payment services. The complete list of targeted Android packages is provided in the Targeted Application List section.
Once Accessibility Service is granted, GhostBat RAT monitors foreground activity and determines whether the currently running application(s) match an entry in pin_target_packages. The malware then evaluates the surrounding application and screen context before treating observed numeric input as potentially sensitive PIN information.
Figure 15 – PIN target package list
The malware also uses configurable PIN-length boundaries, pin_min_digits, and pin_min_digits to determine whether the reconstructed numeric sequence is consistent with an expected PIN.
Unlike Ghost Overlay, the broader keylogging mechanism does not rely on a transparent keypad overlay. Instead, GhostBat RAT uses Accessibility Service events and UI context to identify and reconstruct PIN-like input across a wider set of targeted financial applications, giving the malware substantially broader coverage within India’s banking and digital payment ecosystem.
The analyzed variant contains a dedicated worker responsible for handling captured PIN information, “PinUploadWorker”. Captured PINS are locally queued before being transmitted to the endpoint “/pin-data”.
Figure 16 – Captured PIN upload activity
The introduction of this capability substantially expands the financial targeting of GhostBat RAT. Earlier variants primarily relied on SMS interception, OTP theft, phishing interfaces, and call-forwarding manipulation.
The new variant can also monitor user interactions within legitimate financial applications and capture PIN-like input via Accessibility Service abuse.
Command and Control Infrastructure
The latest GhostBat RAT variant uses a multi-channel command-and-control architecture that combines a conventional HTTPS backend with Firebase services and a configurable WebSocket tunnel.
Compared with earlier variants, which relied more heavily on hardcoded infrastructure, the new implementation provides greater operational flexibility by allowing the attacker to modify backend addresses and enable or disable selected malware capabilities remotely.
In the analyzed sample, the default C&C infrastructure was configured as hxxps://api[.]cloudsettle[.]org. The malware communicates with this backend via multiple REST API endpoints that handle device registration, SMS collection, call log collection, command acknowledgement, PIN data submission, service state reporting, and other post-compromise functionality.
Endpoint
Purpose
/sms/batch
Uploads batches of SMS messages collected from the infected device
/sms/new
Sends newly received SMS messages to the C&C in near real time
/sms/delivery-status
Reports the delivery or failure status of remotely sent SMS messages
/call-logs/batch
Uploads collected call-log records in bulk
/call-logs/new
Sends newly observed call-log entries to the C&C
/devices/sim-info
Sends SIM and telephony-related information from the infected device
/devices/update-token
Registers or updates the device’s Firebase Cloud Messaging token
/devices/service-status
Reports the operational status of malware services running on the device
/commands/ack
Acknowledges receipt or execution of commands issued by the C&C
/commands/call-forward/status
Reports the result or current state of call-forwarding operations
/ping-response
Responds to C&C ping requests and confirms that the infected device is online
/upload-response
Returns the result or status of generic upload or command operations
/pin-data
Uploads captured PIN-related data, including Ghost Overlay and broader PIN-capture records
/live-keylog/status
Reports or manages the operational state of the live keylogging functionality
One of the major changes in the latest GhostBat RAT variant is the use of Firebase Remote Config as an additional control layer. The analyzed payload is associated with the Firebase project andromeda-d389d and retrieves remotely managed configuration values that control both infrastructure and malware functionality.
Of particular interest is the base_url parameter, which allows the operator to replace the active REST backend without modifying or redistributing the APK. Therefore, api.cloudsettle.org represents the observed/default backend for this sample rather than a permanently fixed C&C address.
Figure 17 – Dynamic C&C implementation
A similar dynamic C&C approach was observed during the GhostX investigation. An earlier NextGen mParivahan sample associated with the ghostx-panel Firebase project retrieved its backend configuration from Firestore using the app_config/network document and the baseUrl field.
In addition to the newly introduced Accessibility Service abuse, Ghost Overlay, targeted PIN capture, and dynamically configurable C&C functionality, GhostBat RAT continues to exhibit several core behaviors documented in our earlier research.
These include collecting SMS messages from compromised devices, monitoring newly received messages for banking- and OTP-related content, stealing UPI credentials through fraudulent mParivahan payment interfaces, and registering compromised devices with attacker-controlled infrastructure.
Earlier GhostBat RAT variants also used Telegram bots for device registration and operator notification, while selected dropper chains contained cryptocurrency-mining functionality alongside the information-stealing payload.
These previously documented capabilities remain important to the overall GhostBat RAT operation; however, the latest variants significantly expand the malware’s financial-theft and remote-control functionality.
Rather than repeating the earlier functionality in detail, this analysis focuses on newly observed capabilities and architectural changes, particularly Accessibility Service abuse, Ghost Overlay PIN interception, broader targeting of financial applications, dynamic Firebase-based configuration, and evolving loader and C2 mechanisms.
Conclusion
The latest GhostBat RAT activity highlights continued evolution across both delivery mechanisms and post-compromise capabilities. The investigation into mParivahan- and eChallan-themed malware exposed the broader GhostX ecosystem, linking phishing infrastructure, backend control, and evolving GhostBat RAT payloads.
The introduction of Accessibility Service abuse, Ghost Overlay, broader PIN capture, and Firebase-driven dynamic configuration significantly expands the malware’s financial-theft capabilities while making the operation more adaptable. Combined with continuously evolving loaders and active phishing activity, GhostBat RAT remains a threat to Android users, particularly across India’s banking, UPI, and digital payment ecosystem.
Cyble’s Threat Intelligence Platformscontinuously monitor emerging threats, infrastructure, and activity across thedark web,deep web, and open sources.This proactive intelligence empowers organizations with early detection, impersonation, infrastructure mapping, and attribution insights. Altogether, these capabilities provide a critical head start in mitigating and responding to evolvingcyber threats.
CRIL’s analysis of this campaign has been selected for the upcoming Association of Anti-Virus Asia Researchers (AVAR) conference, where these findings will be showcased.
Our Recommendations
We have listed essential cybersecurity best practices that form the first line of defense against attackers. We recommend that our readers follow the best practices given below:
Install Apps Only from Trusted Sources: Download apps exclusively from official platforms like the Google Play Store. Avoid third-party app stores or links received via SMS, social media, or email.
Be Cautious with Permissions and Installs: Never grant permissions and install an application unless you’re certain of an app’s legitimacy.
Watch for Phishing Pages: Always verify the URL and avoid suspicious links and websites that ask for sensitive information.
Enable Multi-Factor Authentication (MFA): Use MFA for banking and financial apps to add an extra layer of protection, even if credentials are compromised.
Report Suspicious Activity: If you suspect you’ve been targeted or infected, report the incident to your bank and local authorities immediately. If necessary, reset your credentials and perform a factory reset.
Use Mobile Security Solutions: Install a mobile security application that includes real-time scanning.
Keep Your Device Updated: Ensure your Android OS and apps are updated regularly. Security patches often address vulnerabilities that malware exploits.
MITRE ATT&CK® Techniques
Tactic
Technique ID
Procedure
Initial Access
Phishing (T1660)
GhostBat RAT is distributed through smishing messages containing malicious links that redirect victims to fake mParivahan/eChallan or Google Play-style pages used to deliver the malicious APK.
GhostBat RAT uses a boot-triggered Broadcast Receiver to restart its malicious services and workers after device reboot, allowing the implant to resume background activity.
Defense Evasion
Masquerading: Match Legitimate Name or Location (T1655.001)
GhostBat RAT masquerades as legitimate mParivahan/eChallan applications and uses government-themed names, icons, and interfaces to deceive victims.
Defense Evasion
Obfuscated Files or Information: Software Packing (T1406.002)
GhostBat RAT uses multiple encrypted and packed loader mechanisms, including AES-CBC, XOR, SPKZ/SPK1, encrypted DEX stages, and the libnetbridge.so multi-stage loader to conceal the final payload.
Defense Evasion
Download New Code at Runtime (T1407)
One observed GhostBat RAT delivery variant remotely downloads a second-stage APK, validates the payload, and installs it after the initial dropper executes.
Defense Evasion
Input Injection (T1516)
GhostBat RAT abuses AccessibilityService.dispatchGesture() to replay intercepted PIN-keypad touches into legitimate Google Pay and MobiKwik applications as part of the Ghost Overlay technique.
Credential Access
Abuse Accessibility Features (T1453)
The latest GhostBat RAT variant abuses Android Accessibility Service to monitor targeted financial applications, identify PIN-entry contexts, capture sensitive input, and support Ghost Overlay activity.
Credential Access
Input Capture: Keylogging (T1417.001)
GhostBat RAT uses Accessibility Service events to capture PIN/key-input activity from targeted financial applications. The default configuration targets 60 Android banking, UPI, wallet, fintech, and payment applications.
Credential Access
Input Capture: GUI Input Capture (T1417.002)
Selected GhostBat RAT variants use fraudulent payment interfaces to capture UPI PINs, payment-card details, and other financial information entered by victims.
Credential Access
Access Notifications (T1517)
Selected GhostBat RAT variants register a notification-listener service to monitor notifications generated by other applications, potentially exposing OTPs and other sensitive information.
Discovery
System Information Discovery (T1426)
GhostBat RAT collects device information including Android version, device model, manufacturer, identifiers, and other system metadata.
Discovery
Software Discovery (T1418)
GhostBat RAT can enumerate applications installed on the compromised device and uses package information to identify targeted banking and financial applications.
Collection
Protected User Data: SMS Messages (T1636.004)
GhostBat RAT collects historical SMS messages and monitors newly received messages, including OTPs, banking alerts, and other sensitive message content.
Collection
Protected User Data: Call Log (T1636.002)
GhostBat RAT collects call-history information and uploads historical and newly observed call-log records through its C2 infrastructure.
Impact
SMS Control (T1582)
GhostBat RAT can receive attacker-defined SMS jobs and send messages through the infected device’s SIM, allowing compromised devices to be used for remotely controlled SMS transmission and potentially further smishing activity.
Impact
Call Control (T1616)
GhostBat RAT can manipulate and query call forwarding using USSD-based operations and report the forwarding state to its C2 infrastructure.
Command and Control
Application Layer Protocol: Web Protocols (T1437.001)
GhostBat RAT communicates with its backend through HTTPS REST APIs and uses Firebase Cloud Messaging for command delivery. The latest variant also contains a configurable secure WebSocket communication channel.
GhostBat RAT continues to target Android users in India via mParivahan- and eChallan-themed smishing campaigns, using phishing pages and public hosting platforms to distribute malicious APKs.
Our investigation uncovered GhostX, a broader operator-controlled ecosystem that supports phishing, device management, backend configuration, and the distribution of the GhostBat RAT.
The latest GhostBat RAT variant abuses the Android Accessibility Service, including the Ghost Overlay technique to intercept PIN entry in legitimate Google Pay and MobiKwik applications.
The malware also implements broader PIN/key-input capture targeting 60 Android applications associated with India’s banking, UPI, wallet, fintech, and digital-payment ecosystem.
GhostBat RAT’s delivery layer has evolved through multiple loader and dropper implementations, with the latest libnetbridge.so loader employing several transformations, including encryption, compression, and custom container stages, before recovering the final payload.
Firebase Remote Config enables dynamic C&C and feature management, allowing operators to modify backend infrastructure and selected malware capabilities without rebuilding or redistributing the APK.
Overview
In October 2025, Cyble identified GhostBat RAT being distributed through MiningDropper and targeting Android users in India.
We have since continued to track related activity and investigate malicious applications impersonating India’s mParivahan and eChallan services. This research uncovered a broader Android threat ecosystem that we track as GhostX, along with significantly evolved variants of GhostBat RAT.
The most recent GhostBat RAT variant demonstrates a notable increase in capability and operational flexibility. It uses Firebase Remote Config to dynamically manage command-and-control (C&C) infrastructure and to enable or disable individual malware modules without requiring APK redistribution.
This variant also implements a sophisticated Ghost Overlay technique targeting legitimate Google Pay and MobiKwik PIN-entry interfaces. Instead of displaying a conventional fake login page, the malware places transparent accessibility overlays over the legitimate application’s keypad, records the victim’s touch selections, and replays the same interaction into the genuine application.
Additionally, the malware implements a PIN-capture capability through keylogging, targeting 60 Android applications across India’s banking, UPI, wallet, fintech, and digital payment ecosystem.
The malware’s delivery and packing mechanisms have evolved considerably across the samples analyzed. We identified at least six distinct loader or dropper implementations, including:
Native AES-CBC-protected APK containers
Custom SPKZ/SPK1 payload formats
Java-based in-memory DEX loaders
Remote APK downloaders
Multi-stage XOR/AES loaders
A newer native libnetbridge.so loader using multiple cryptographic, transformation, compression, and custom container stages before recovering the final payload
This diversification suggests continued investment in defeating static detection and complicating automated malware extraction.
GhostBat RAT is primarily distributed via smishing messages that contain malicious links. When victims follow these links, they are redirected to phishing pages that impersonate either the legitimate Parivahan service or a Google Play-style application download page and are encouraged to install a fraudulent mParivahan APK (see Figures 2 and 3).
During our investigation, we also repeatedly observed GitHub repositories and GitHub-hosted assets being used to distribute malicious APKs, providing attackers with readily available public hosting infrastructure.
Figure 2 – Fake Google Play Store-style mParivahan installation websiteFigure 3 – Fake mParivahan website prompting to download APK file
Discovery of the GhostX Ecosystem
The GhostX investigation began with the discovery of multiple Android applications impersonating India’s mParivahan and eChallan ecosystem.
Samples were collected from phishing infrastructure and public GitHub repositories containing APKs named or presented as mParivahan, vehicle-challan, traffic-enforcement, or other related government applications.
Initial static analysis revealed that many of these APKs were only first-stage loaders. Their visible DEX code offered limited functionality, while the actual malware payload was either concealed within encrypted assets or retrieved later.
After unpacking the applications to their final payloads, we identified multiple custom C&C infrastructures, Firebase projects, and overlapping Android surveillance and financial-fraud capabilities.
A major breakthrough came from the analysis of a NextGen mParivahan sample whose unpacked payload contained the Firebase project identifier:
ghostx-panel
The exposed Firebase backend provided significantly greater visibility into the operator’s infrastructure and control workflow. The database contained structures including:
clients
bot_users
admins
admin_logins
settings
All_Users
Verify_Device
Analysis of the exposed GhostX backend revealed evidence of a structured operator-management layer beyond conventional malware C&C functionality.
The database contained administrator and user records with role and account-status fields, a global session identifier, bot-user mappings, and dedicated admin_logins records containing device fingerprints, timestamps, and online status (see Figure 4).
These artifacts indicate that GhostX incorporates an authentication and session management framework for operator-side access and management of compromised devices.
The presence of distinct user, administrator, and bot-user roles suggests a multi-operator, service-oriented architecture. It raises the possibility that GhostX could support a Malware-as-a-Service-style operating model.
Figure 4 – Exposed administrative records.
During continued monitoring of the exposed infrastructure, we observed that SMS lure content, phishing URLs, vehicle registration numbers, and recipient phone numbers were repeatedly changing, indicating active operator-side campaign management rather than a static or abandoned database (see Figure 5).
Similar eChallan-themed messages were also observed being received by users in the wild, further supporting the campaign’s operational nature (see Figure 6).
Figure 5 – Exposed SMS message configured to be sent to victimsFigure 6 – Same SMSs are being received by the victims (Source – Twitter Post)
One of the phishing URLs exposed through the GhostX infrastructure subsequently led us to a previously unseen GhostBat RAT variant, providing a direct investigative link among the backend control ecosystem, active phishing operations, and the malware’s continued evolution.
These findings led us to assess that GhostX is not a single Android malware family or standalone application. Instead, GhostX represents a broader operator-controlled ecosystem encompassing phishing infrastructure, backend services, Firebase-based configuration and command mechanisms, device-management functionality, and malware distribution.
GhostBat RAT represents the Android implant operating within this ecosystem, with individual variants continuing to evolve across both delivery mechanisms and post-compromise capabilities.
Technical Analysis
Evolution of Droppers and Loaders
GhostBat RAT has undergone continuous changes in its delivery and payload-protection mechanisms.
Across the samples analyzed during the GhostX investigation, we identified multiple loader and dropper implementations designed to conceal the underlying malware payload, complicate static analysis, and reduce the effectiveness of hash- and signature-based detection.
Although the recovered payloads demonstrate overlapping capabilities for surveillance, financial theft, and device control, the mechanisms used to deliver and recover them vary considerably across samples.
Earlier variants relied on comparatively straightforward native loaders that decrypted embedded APK payloads using AES-CBC. Subsequent variants of Ghostbat RAT introduced XOR-encrypted custom containers, SPKZ/SPK1 packaging, split-APK delivery, dynamically loaded DEX components, and Java-based in-memory loaders.
One variant moved away from embedded payload delivery entirely. It operated as a remote downloader, retrieving a second-stage APK from remote infrastructure, validating its SHA-256 hash, and installing it through Android’s package installation framework.
The most recent variant analyzed introduces a substantially more complex native loader implemented in libnetbridge.so. This loader combines multiple transformations, encryption, compression, and custom container stages before recovering the final GhostBat RAT payload.
This diversification indicates continued modification of the delivery layer while broadly retaining the malware’s post-compromise objectives. Consequently, detections that focus only on the outer APK, the encrypted asset name, or a single unpacking routine are unlikely to provide durable coverage.
The GhostBat RAT loaders/droppers variants we observed are listed below:
Figure 7 – GhostBat RAT Loader variants
The most recent GhostBat RAT sample introduced a significantly more complex native unpacking mechanism.
Unlike earlier variants that relied primarily on Java-based loaders or comparatively straightforward XOR/AES routines, this variant stores the encrypted payload inside an opaque application asset, assets/isti52q4, while most of the unpacking logic is implemented in the native library libnetbridge.so.
The visible application code does not directly expose the final malicious functionality. Instead, execution transitions to the native loader, which processes the embedded asset through several sequential stages of transformation and decryption (see Figure 8).
Figure 8 – Latest native dropper unpacking chain
The first stage processes content within the encrypted asset file and derives values required for subsequent decoding. The resulting data is then passed through an RC4-like transformation before being processed through AES-256-GCM. This layered approach prevents the encrypted asset from being recovered using simple XOR or direct AES key extraction techniques that worked against earlier GhostBat RAT loaders.
Following successful decryption, the loader recovers an MSZ1-formatted intermediate object that is decompressed using zlib. The decompressed data contains an MSP1 container that packages the final Android application components.
The recovered payload consists of a split-APK application, including base.apk and split_config.dex.apk.
The executable malware code is primarily contained within the recovered split configuration DEX.
Unlike earlier samples, where the encrypted payload could be identified directly from ZIP headers or standard APK structures, the latest loader hides the final application behind several custom transformations before any recognizable Android package becomes available.
This significantly increases the effort required for automated unpacking and reduces the effectiveness of simple asset-scanning techniques.
Advanced GhostBat RAT Payload
GhostBat RAT has evolved from an Android SMS and information stealer into a modular remote-access and Banking Trojan.
Across the analyzed variants, the malware demonstrates capabilities for device profiling, SMS interception, remote SMS transmission, call-forwarding manipulation, payment-data theft, accessibility-based PIN capture, Firebase-driven command delivery, dynamic C&C configuration, and remote tunnelling.
In the new GhostBat RAT variant, we observed the introduction of Android Accessibility Service abuse, a technique commonly associated with modern Android Banking Trojans.
Earlier GhostBat RAT variants that we analyzed did not possess these capabilities during this investigation. The new variant uses Accessibility Service to monitor foreground applications, identify PIN-entry contexts, interact with application interfaces, and support two distinct credential-theft mechanisms: Ghost Overlay and targeted PIN/key-input capture.
Once Accessibility Services access is granted, the malware monitors the foreground application and compares it against configured target lists. These targets can be managed through Firebase Remote Config, allowing operators to selectively activate credential-capture functionality when a targeted banking, UPI, wallet, or payment application is in use.
Ghost Overlay
The most notable capability introduced in this variant is the Ghost Overlay technique.
Figure 9.1 – Ghost Overlay Attack Flow
Unlike conventional Android overlay attacks that display a fake login or payment page over the legitimate application, GhostBat RAT does not need to replace the victim’s banking interface. Instead, it places transparent accessibility overlay regions directly over the real PIN keypad displayed by the targeted application.
The feature is controlled through Firebase Remote Config using:
The default Ghost Overlay configuration targets the following Android packages:
com.mobikwik_new
com.google.android.apps.nbu.paisa
com.google.android.apps.nbu.paisa.user
Figure 10 – Target package list of Ghost Overlay activity
When the malware detects one of these applications in the foreground and identifies a PIN-related activity, it creates a transparent keypad grid using Android’s TYPE_ACCESSIBILITY_OVERLAY. The overlay contains 12 touch regions matching the layout of a typical numeric PIN pad (see Figures 11 and 12):
When the victim taps a digit on the legitimate Google Pay or MobiKwik PIN keypad, the transparent Ghost Overlay intercepts the touch event before it reaches the underlying application.
The malware maps the touch coordinates to the corresponding keypad value and appends the resulting digit to an internal buffer used to reconstruct the PIN.
To avoid interrupting the payment flow or alerting the victim, GhostBat RAT temporarily releases the affected overlay region and uses AccessibilityService.dispatchGesture() to reproduce the same tap at the corresponding screen coordinates (see Figure 13).
As a result, the legitimate application receives the expected input and continues operating normally, while the malware records the victim’s PIN in parallel.
The same mechanism handles DEL and OK interactions, allowing the GhostBat RAT to update the captured digit sequence and detect when the PIN entry process has completed. This intercept-and-replay behavior enables the malware to observe PIN entry without presenting a fake Google Pay or MobiKwik interface.
Figure 13 – dispatchGesture activity
Once collected, the PIN is stored with metadata identifying the capture source as ghost_overlay and is subsequently queued for exfiltration over C&C “hxxps://api.cloudsettle[.]org/pin-data” (see Figure 14).
Figure 14 – Storing captured Ghost PIN
This technique is considerably stealthier than a conventional phishing overlay because the victim remains within the genuine financial application’s interface throughout the interaction. GhostBat RAT effectively operates as an invisible intermediary, intercepting the victim’s keypad interaction, recording the selected digits, and replaying those same touches into the legitimate application in near real time.
Targeted Keylogging and PIN Capture
In addition to the Ghost Overlay capability, the new GhostBat RAT variant implements a broader accessibility-based PIN/key-input capture mechanism targeting applications across India’s banking, UPI, wallet, fintech, and digital-payment ecosystem.
Unlike the Ghost Overlay feature, which is specifically designed to intercept keypad touches in Google Pay and MobiKwik via transparent overlay regions, this functionality relies on Android Accessibility Service events to monitor user interactions across a much larger set of targeted applications.
The default pin_target_packages configuration includes 60 Android package identifiers for financial applications used across India (see Figure 15).
The target set includes applications associated with Google Pay, PhonePe, Paytm, MobiKwik, BHIM, SBI UPI, Axis Pay, BharatPe, CRED, Freecharge, PayZapp, Groww, Navi, Jupiter, OneCard, JioFinance, Samsung Pay, and several other banking and payment services. The complete list of targeted Android packages is provided in the Targeted Application List section.
Once Accessibility Service is granted, GhostBat RAT monitors foreground activity and determines whether the currently running application(s) match an entry in pin_target_packages. The malware then evaluates the surrounding application and screen context before treating observed numeric input as potentially sensitive PIN information.
Figure 15 – PIN target package list
The malware also uses configurable PIN-length boundaries, pin_min_digits, and pin_min_digits to determine whether the reconstructed numeric sequence is consistent with an expected PIN.
Unlike Ghost Overlay, the broader keylogging mechanism does not rely on a transparent keypad overlay. Instead, GhostBat RAT uses Accessibility Service events and UI context to identify and reconstruct PIN-like input across a wider set of targeted financial applications, giving the malware substantially broader coverage within India’s banking and digital payment ecosystem.
The analyzed variant contains a dedicated worker responsible for handling captured PIN information, “PinUploadWorker”. Captured PINS are locally queued before being transmitted to the endpoint “/pin-data”.
Figure 16 – Captured PIN upload activity
The introduction of this capability substantially expands the financial targeting of GhostBat RAT. Earlier variants primarily relied on SMS interception, OTP theft, phishing interfaces, and call-forwarding manipulation.
The new variant can also monitor user interactions within legitimate financial applications and capture PIN-like input via Accessibility Service abuse.
Command and Control Infrastructure
The latest GhostBat RAT variant uses a multi-channel command-and-control architecture that combines a conventional HTTPS backend with Firebase services and a configurable WebSocket tunnel.
Compared with earlier variants, which relied more heavily on hardcoded infrastructure, the new implementation provides greater operational flexibility by allowing the attacker to modify backend addresses and enable or disable selected malware capabilities remotely.
In the analyzed sample, the default C&C infrastructure was configured as hxxps://api[.]cloudsettle[.]org. The malware communicates with this backend via multiple REST API endpoints that handle device registration, SMS collection, call log collection, command acknowledgement, PIN data submission, service state reporting, and other post-compromise functionality.
Endpoint
Purpose
/sms/batch
Uploads batches of SMS messages collected from the infected device
/sms/new
Sends newly received SMS messages to the C&C in near real time
/sms/delivery-status
Reports the delivery or failure status of remotely sent SMS messages
/call-logs/batch
Uploads collected call-log records in bulk
/call-logs/new
Sends newly observed call-log entries to the C&C
/devices/sim-info
Sends SIM and telephony-related information from the infected device
/devices/update-token
Registers or updates the device’s Firebase Cloud Messaging token
/devices/service-status
Reports the operational status of malware services running on the device
/commands/ack
Acknowledges receipt or execution of commands issued by the C&C
/commands/call-forward/status
Reports the result or current state of call-forwarding operations
/ping-response
Responds to C&C ping requests and confirms that the infected device is online
/upload-response
Returns the result or status of generic upload or command operations
/pin-data
Uploads captured PIN-related data, including Ghost Overlay and broader PIN-capture records
/live-keylog/status
Reports or manages the operational state of the live keylogging functionality
One of the major changes in the latest GhostBat RAT variant is the use of Firebase Remote Config as an additional control layer. The analyzed payload is associated with the Firebase project andromeda-d389d and retrieves remotely managed configuration values that control both infrastructure and malware functionality.
Of particular interest is the base_url parameter, which allows the operator to replace the active REST backend without modifying or redistributing the APK. Therefore, api.cloudsettle.org represents the observed/default backend for this sample rather than a permanently fixed C&C address.
Figure 17 – Dynamic C&C implementation
A similar dynamic C&C approach was observed during the GhostX investigation. An earlier NextGen mParivahan sample associated with the ghostx-panel Firebase project retrieved its backend configuration from Firestore using the app_config/network document and the baseUrl field.
In addition to the newly introduced Accessibility Service abuse, Ghost Overlay, targeted PIN capture, and dynamically configurable C&C functionality, GhostBat RAT continues to exhibit several core behaviors documented in our earlier research.
These include collecting SMS messages from compromised devices, monitoring newly received messages for banking- and OTP-related content, stealing UPI credentials through fraudulent mParivahan payment interfaces, and registering compromised devices with attacker-controlled infrastructure.
Earlier GhostBat RAT variants also used Telegram bots for device registration and operator notification, while selected dropper chains contained cryptocurrency-mining functionality alongside the information-stealing payload.
These previously documented capabilities remain important to the overall GhostBat RAT operation; however, the latest variants significantly expand the malware’s financial-theft and remote-control functionality.
Rather than repeating the earlier functionality in detail, this analysis focuses on newly observed capabilities and architectural changes, particularly Accessibility Service abuse, Ghost Overlay PIN interception, broader targeting of financial applications, dynamic Firebase-based configuration, and evolving loader and C2 mechanisms.
Conclusion
The latest GhostBat RAT activity highlights continued evolution across both delivery mechanisms and post-compromise capabilities. The investigation into mParivahan- and eChallan-themed malware exposed the broader GhostX ecosystem, linking phishing infrastructure, backend control, and evolving GhostBat RAT payloads.
The introduction of Accessibility Service abuse, Ghost Overlay, broader PIN capture, and Firebase-driven dynamic configuration significantly expands the malware’s financial-theft capabilities while making the operation more adaptable. Combined with continuously evolving loaders and active phishing activity, GhostBat RAT remains a threat to Android users, particularly across India’s banking, UPI, and digital payment ecosystem.
Cyble’s Threat Intelligence Platformscontinuously monitor emerging threats, infrastructure, and activity across thedark web,deep web, and open sources.This proactive intelligence empowers organizations with early detection, impersonation, infrastructure mapping, and attribution insights. Altogether, these capabilities provide a critical head start in mitigating and responding to evolvingcyber threats.
CRIL’s analysis of this campaign has been selected for the upcoming Association of Anti-Virus Asia Researchers (AVAR) conference, where these findings will be showcased.
Our Recommendations
We have listed essential cybersecurity best practices that form the first line of defense against attackers. We recommend that our readers follow the best practices given below:
Install Apps Only from Trusted Sources: Download apps exclusively from official platforms like the Google Play Store. Avoid third-party app stores or links received via SMS, social media, or email.
Be Cautious with Permissions and Installs: Never grant permissions and install an application unless you’re certain of an app’s legitimacy.
Watch for Phishing Pages: Always verify the URL and avoid suspicious links and websites that ask for sensitive information.
Enable Multi-Factor Authentication (MFA): Use MFA for banking and financial apps to add an extra layer of protection, even if credentials are compromised.
Report Suspicious Activity: If you suspect you’ve been targeted or infected, report the incident to your bank and local authorities immediately. If necessary, reset your credentials and perform a factory reset.
Use Mobile Security Solutions: Install a mobile security application that includes real-time scanning.
Keep Your Device Updated: Ensure your Android OS and apps are updated regularly. Security patches often address vulnerabilities that malware exploits.
MITRE ATT&CK® Techniques
Tactic
Technique ID
Procedure
Initial Access
Phishing (T1660)
GhostBat RAT is distributed through smishing messages containing malicious links that redirect victims to fake mParivahan/eChallan or Google Play-style pages used to deliver the malicious APK.
GhostBat RAT uses a boot-triggered Broadcast Receiver to restart its malicious services and workers after device reboot, allowing the implant to resume background activity.
Defense Evasion
Masquerading: Match Legitimate Name or Location (T1655.001)
GhostBat RAT masquerades as legitimate mParivahan/eChallan applications and uses government-themed names, icons, and interfaces to deceive victims.
Defense Evasion
Obfuscated Files or Information: Software Packing (T1406.002)
GhostBat RAT uses multiple encrypted and packed loader mechanisms, including AES-CBC, XOR, SPKZ/SPK1, encrypted DEX stages, and the libnetbridge.so multi-stage loader to conceal the final payload.
Defense Evasion
Download New Code at Runtime (T1407)
One observed GhostBat RAT delivery variant remotely downloads a second-stage APK, validates the payload, and installs it after the initial dropper executes.
Defense Evasion
Input Injection (T1516)
GhostBat RAT abuses AccessibilityService.dispatchGesture() to replay intercepted PIN-keypad touches into legitimate Google Pay and MobiKwik applications as part of the Ghost Overlay technique.
Credential Access
Abuse Accessibility Features (T1453)
The latest GhostBat RAT variant abuses Android Accessibility Service to monitor targeted financial applications, identify PIN-entry contexts, capture sensitive input, and support Ghost Overlay activity.
Credential Access
Input Capture: Keylogging (T1417.001)
GhostBat RAT uses Accessibility Service events to capture PIN/key-input activity from targeted financial applications. The default configuration targets 60 Android banking, UPI, wallet, fintech, and payment applications.
Credential Access
Input Capture: GUI Input Capture (T1417.002)
Selected GhostBat RAT variants use fraudulent payment interfaces to capture UPI PINs, payment-card details, and other financial information entered by victims.
Credential Access
Access Notifications (T1517)
Selected GhostBat RAT variants register a notification-listener service to monitor notifications generated by other applications, potentially exposing OTPs and other sensitive information.
Discovery
System Information Discovery (T1426)
GhostBat RAT collects device information including Android version, device model, manufacturer, identifiers, and other system metadata.
Discovery
Software Discovery (T1418)
GhostBat RAT can enumerate applications installed on the compromised device and uses package information to identify targeted banking and financial applications.
Collection
Protected User Data: SMS Messages (T1636.004)
GhostBat RAT collects historical SMS messages and monitors newly received messages, including OTPs, banking alerts, and other sensitive message content.
Collection
Protected User Data: Call Log (T1636.002)
GhostBat RAT collects call-history information and uploads historical and newly observed call-log records through its C2 infrastructure.
Impact
SMS Control (T1582)
GhostBat RAT can receive attacker-defined SMS jobs and send messages through the infected device’s SIM, allowing compromised devices to be used for remotely controlled SMS transmission and potentially further smishing activity.
Impact
Call Control (T1616)
GhostBat RAT can manipulate and query call forwarding using USSD-based operations and report the forwarding state to its C2 infrastructure.
Command and Control
Application Layer Protocol: Web Protocols (T1437.001)
GhostBat RAT communicates with its backend through HTTPS REST APIs and uses Firebase Cloud Messaging for command delivery. The latest variant also contains a configurable secure WebSocket communication channel.
Cyble has continued tracking GhostBat RAT activity targeting Android users in India since its initial identification in October 2025. Recent investigations into malicious mParivahan and eChallan-themed applications revealed a broader operator-controlled ecosystem that we track as GhostX.
Analysis of the exposed GhostX backend identified administrative and user-management structures, device-control records, SMS-delivery instructions, call-forwarding activity, and continuously changing phishing content, indicating active campaign management.
Impressions
The latest GhostBat RAT variant represents a significant evolution in both delivery and post-compromise capabilities. The malware now abuses the Android Accessibility Service to support Ghost Overlay and broader PIN/key-input capture targeting financial applications used across India.
Ghost Overlay transparently intercepts PIN keypad interactions in Google Pay and MobiKwik. It replays the same touches into the legitimate application, allowing the malware to capture PIN information without presenting a conventional phishing interface. The variant also targets 60 banking, UPI, wallet, fintech, and payment applications for broader PIN capture.
Modus Operandi
GhostBat RAT has diversified its loader architecture, with at least six observed delivery mechanisms, while the latest build uses libnetbridge.so and multiple cryptographic and custom container stages. Firebase Remote Config further enables operators to dynamically modify C&C infrastructure and malware functionality after installation.
Figure 1 – GhostBat RAT Infection Chain
Key Takeaways
GhostBat RAT continues to target Android users in India via mParivahan- and eChallan-themed smishing campaigns, using phishing pages and public hosting platforms to distribute malicious APKs.
Our investigation uncovered GhostX, a broader operator-controlled ecosystem that supports phishing, device management, backend configuration, and the distribution of the GhostBat RAT.
The latest GhostBat RAT variant abuses the Android Accessibility Service, including the Ghost Overlay technique to intercept PIN entry in legitimate Google Pay and MobiKwik applications.
The malware also implements broader PIN/key-input capture targeting 60 Android applications associated with India’s banking, UPI, wallet, fintech, and digital-payment ecosystem.
GhostBat RAT’s delivery layer has evolved through multiple loader and dropper implementations, with the latest libnetbridge.so loader employing several transformations, including encryption, compression, and custom container stages, before recovering the final payload.
Firebase Remote Config enables dynamic C&C and feature management, allowing operators to modify backend infrastructure and selected malware capabilities without rebuilding or redistributing the APK.
Overview
In October 2025, Cyble identified GhostBat RAT being distributed through MiningDropper and targeting Android users in India.
We have since continued to track related activity and investigate malicious applications impersonating India’s mParivahan and eChallan services. This research uncovered a broader Android threat ecosystem that we track as GhostX, along with significantly evolved variants of GhostBat RAT.
The most recent GhostBat RAT variant demonstrates a notable increase in capability and operational flexibility. It uses Firebase Remote Config to dynamically manage command-and-control (C&C) infrastructure and to enable or disable individual malware modules without requiring APK redistribution.
This variant also implements a sophisticated Ghost Overlay technique targeting legitimate Google Pay and MobiKwik PIN-entry interfaces. Instead of displaying a conventional fake login page, the malware places transparent accessibility overlays over the legitimate application’s keypad, records the victim’s touch selections, and replays the same interaction into the genuine application.
Additionally, the malware implements a PIN-capture capability through keylogging, targeting 60 Android applications across India’s banking, UPI, wallet, fintech, and digital payment ecosystem.
The malware’s delivery and packing mechanisms have evolved considerably across the samples analyzed. We identified at least six distinct loader or dropper implementations, including:
Native AES-CBC-protected APK containers
Custom SPKZ/SPK1 payload formats
Java-based in-memory DEX loaders
Remote APK downloaders
Multi-stage XOR/AES loaders
A newer native libnetbridge.so loader using multiple cryptographic, transformation, compression, and custom container stages before recovering the final payload
This diversification suggests continued investment in defeating static detection and complicating automated malware extraction.
GhostBat RAT is primarily distributed via smishing messages that contain malicious links. When victims follow these links, they are redirected to phishing pages that impersonate either the legitimate Parivahan service or a Google Play-style application download page and are encouraged to install a fraudulent mParivahan APK (see Figures 2 and 3).
During our investigation, we also repeatedly observed GitHub repositories and GitHub-hosted assets being used to distribute malicious APKs, providing attackers with readily available public hosting infrastructure.
Figure 2 – Fake Google Play Store-style mParivahan installation websiteFigure 3 – Fake mParivahan website prompting to download APK file
Discovery of the GhostX Ecosystem
The GhostX investigation began with the discovery of multiple Android applications impersonating India’s mParivahan and eChallan ecosystem.
Samples were collected from phishing infrastructure and public GitHub repositories containing APKs named or presented as mParivahan, vehicle-challan, traffic-enforcement, or other related government applications.
Initial static analysis revealed that many of these APKs were only first-stage loaders. Their visible DEX code offered limited functionality, while the actual malware payload was either concealed within encrypted assets or retrieved later.
After unpacking the applications to their final payloads, we identified multiple custom C&C infrastructures, Firebase projects, and overlapping Android surveillance and financial-fraud capabilities.
A major breakthrough came from the analysis of a NextGen mParivahan sample whose unpacked payload contained the Firebase project identifier:
ghostx-panel
The exposed Firebase backend provided significantly greater visibility into the operator’s infrastructure and control workflow. The database contained structures including:
clients
bot_users
admins
admin_logins
settings
All_Users
Verify_Device
Analysis of the exposed GhostX backend revealed evidence of a structured operator-management layer beyond conventional malware C&C functionality.
The database contained administrator and user records with role and account-status fields, a global session identifier, bot-user mappings, and dedicated admin_logins records containing device fingerprints, timestamps, and online status (see Figure 4).
These artifacts indicate that GhostX incorporates an authentication and session management framework for operator-side access and management of compromised devices.
The presence of distinct user, administrator, and bot-user roles suggests a multi-operator, service-oriented architecture. It raises the possibility that GhostX could support a Malware-as-a-Service-style operating model.
Figure 4 – Exposed administrative records.
During continued monitoring of the exposed infrastructure, we observed that SMS lure content, phishing URLs, vehicle registration numbers, and recipient phone numbers were repeatedly changing, indicating active operator-side campaign management rather than a static or abandoned database (see Figure 5).
Similar eChallan-themed messages were also observed being received by users in the wild, further supporting the campaign’s operational nature (see Figure 6).
Figure 5 – Exposed SMS message configured to be sent to victimsFigure 6 – Same SMSs are being received by the victims (Source – Twitter Post)
One of the phishing URLs exposed through the GhostX infrastructure subsequently led us to a previously unseen GhostBat RAT variant, providing a direct investigative link among the backend control ecosystem, active phishing operations, and the malware’s continued evolution.
These findings led us to assess that GhostX is not a single Android malware family or standalone application. Instead, GhostX represents a broader operator-controlled ecosystem encompassing phishing infrastructure, backend services, Firebase-based configuration and command mechanisms, device-management functionality, and malware distribution.
GhostBat RAT represents the Android implant operating within this ecosystem, with individual variants continuing to evolve across both delivery mechanisms and post-compromise capabilities.
Technical Analysis
Evolution of Droppers and Loaders
GhostBat RAT has undergone continuous changes in its delivery and payload-protection mechanisms.
Across the samples analyzed during the GhostX investigation, we identified multiple loader and dropper implementations designed to conceal the underlying malware payload, complicate static analysis, and reduce the effectiveness of hash- and signature-based detection.
Although the recovered payloads demonstrate overlapping capabilities for surveillance, financial theft, and device control, the mechanisms used to deliver and recover them vary considerably across samples.
Earlier variants relied on comparatively straightforward native loaders that decrypted embedded APK payloads using AES-CBC. Subsequent variants of Ghostbat RAT introduced XOR-encrypted custom containers, SPKZ/SPK1 packaging, split-APK delivery, dynamically loaded DEX components, and Java-based in-memory loaders.
One variant moved away from embedded payload delivery entirely. It operated as a remote downloader, retrieving a second-stage APK from remote infrastructure, validating its SHA-256 hash, and installing it through Android’s package installation framework.
The most recent variant analyzed introduces a substantially more complex native loader implemented in libnetbridge.so. This loader combines multiple transformations, encryption, compression, and custom container stages before recovering the final GhostBat RAT payload.
This diversification indicates continued modification of the delivery layer while broadly retaining the malware’s post-compromise objectives. Consequently, detections that focus only on the outer APK, the encrypted asset name, or a single unpacking routine are unlikely to provide durable coverage.
The GhostBat RAT loaders/droppers variants we observed are listed below:
Figure 7 – GhostBat RAT Loader variants
The most recent GhostBat RAT sample introduced a significantly more complex native unpacking mechanism.
Unlike earlier variants that relied primarily on Java-based loaders or comparatively straightforward XOR/AES routines, this variant stores the encrypted payload inside an opaque application asset, assets/isti52q4, while most of the unpacking logic is implemented in the native library libnetbridge.so.
The visible application code does not directly expose the final malicious functionality. Instead, execution transitions to the native loader, which processes the embedded asset through several sequential stages of transformation and decryption (see Figure 8).
Figure 8 – Latest native dropper unpacking chain
The first stage processes content within the encrypted asset file and derives values required for subsequent decoding. The resulting data is then passed through an RC4-like transformation before being processed through AES-256-GCM. This layered approach prevents the encrypted asset from being recovered using simple XOR or direct AES key extraction techniques that worked against earlier GhostBat RAT loaders.
Following successful decryption, the loader recovers an MSZ1-formatted intermediate object that is decompressed using zlib. The decompressed data contains an MSP1 container that packages the final Android application components.
The recovered payload consists of a split-APK application, including base.apk and split_config.dex.apk.
The executable malware code is primarily contained within the recovered split configuration DEX.
Unlike earlier samples, where the encrypted payload could be identified directly from ZIP headers or standard APK structures, the latest loader hides the final application behind several custom transformations before any recognizable Android package becomes available.
This significantly increases the effort required for automated unpacking and reduces the effectiveness of simple asset-scanning techniques.
Advanced GhostBat RAT Payload
GhostBat RAT has evolved from an Android SMS and information stealer into a modular remote-access and Banking Trojan.
Across the analyzed variants, the malware demonstrates capabilities for device profiling, SMS interception, remote SMS transmission, call-forwarding manipulation, payment-data theft, accessibility-based PIN capture, Firebase-driven command delivery, dynamic C&C configuration, and remote tunnelling.
In the new GhostBat RAT variant, we observed the introduction of Android Accessibility Service abuse, a technique commonly associated with modern Android Banking Trojans.
Earlier GhostBat RAT variants that we analyzed did not possess these capabilities during this investigation. The new variant uses Accessibility Service to monitor foreground applications, identify PIN-entry contexts, interact with application interfaces, and support two distinct credential-theft mechanisms: Ghost Overlay and targeted PIN/key-input capture.
Once Accessibility Services access is granted, the malware monitors the foreground application and compares it against configured target lists. These targets can be managed through Firebase Remote Config, allowing operators to selectively activate credential-capture functionality when a targeted banking, UPI, wallet, or payment application is in use.
Ghost Overlay
The most notable capability introduced in this variant is the Ghost Overlay technique.
Figure 9.1 – Ghost Overlay Attack Flow
Unlike conventional Android overlay attacks that display a fake login or payment page over the legitimate application, GhostBat RAT does not need to replace the victim’s banking interface. Instead, it places transparent accessibility overlay regions directly over the real PIN keypad displayed by the targeted application.
The feature is controlled through Firebase Remote Config using:
The default Ghost Overlay configuration targets the following Android packages:
com.mobikwik_new
com.google.android.apps.nbu.paisa
com.google.android.apps.nbu.paisa.user
Figure 10 – Target package list of Ghost Overlay activity
When the malware detects one of these applications in the foreground and identifies a PIN-related activity, it creates a transparent keypad grid using Android’s TYPE_ACCESSIBILITY_OVERLAY. The overlay contains 12 touch regions matching the layout of a typical numeric PIN pad (see Figures 11 and 12):
When the victim taps a digit on the legitimate Google Pay or MobiKwik PIN keypad, the transparent Ghost Overlay intercepts the touch event before it reaches the underlying application.
The malware maps the touch coordinates to the corresponding keypad value and appends the resulting digit to an internal buffer used to reconstruct the PIN.
To avoid interrupting the payment flow or alerting the victim, GhostBat RAT temporarily releases the affected overlay region and uses AccessibilityService.dispatchGesture() to reproduce the same tap at the corresponding screen coordinates (see Figure 13).
As a result, the legitimate application receives the expected input and continues operating normally, while the malware records the victim’s PIN in parallel.
The same mechanism handles DEL and OK interactions, allowing the GhostBat RAT to update the captured digit sequence and detect when the PIN entry process has completed. This intercept-and-replay behavior enables the malware to observe PIN entry without presenting a fake Google Pay or MobiKwik interface.
Figure 13 – dispatchGesture activity
Once collected, the PIN is stored with metadata identifying the capture source as ghost_overlay and is subsequently queued for exfiltration over C&C “hxxps://api.cloudsettle[.]org/pin-data” (see Figure 14).
Figure 14 – Storing captured Ghost PIN
This technique is considerably stealthier than a conventional phishing overlay because the victim remains within the genuine financial application’s interface throughout the interaction. GhostBat RAT effectively operates as an invisible intermediary, intercepting the victim’s keypad interaction, recording the selected digits, and replaying those same touches into the legitimate application in near real time.
Targeted Keylogging and PIN Capture
In addition to the Ghost Overlay capability, the new GhostBat RAT variant implements a broader accessibility-based PIN/key-input capture mechanism targeting applications across India’s banking, UPI, wallet, fintech, and digital-payment ecosystem.
Unlike the Ghost Overlay feature, which is specifically designed to intercept keypad touches in Google Pay and MobiKwik via transparent overlay regions, this functionality relies on Android Accessibility Service events to monitor user interactions across a much larger set of targeted applications.
The default pin_target_packages configuration includes 60 Android package identifiers for financial applications used across India (see Figure 15).
The target set includes applications associated with Google Pay, PhonePe, Paytm, MobiKwik, BHIM, SBI UPI, Axis Pay, BharatPe, CRED, Freecharge, PayZapp, Groww, Navi, Jupiter, OneCard, JioFinance, Samsung Pay, and several other banking and payment services. The complete list of targeted Android packages is provided in the Targeted Application List section.
Once Accessibility Service is granted, GhostBat RAT monitors foreground activity and determines whether the currently running application(s) match an entry in pin_target_packages. The malware then evaluates the surrounding application and screen context before treating observed numeric input as potentially sensitive PIN information.
Figure 15 – PIN target package list
The malware also uses configurable PIN-length boundaries, pin_min_digits, and pin_min_digits to determine whether the reconstructed numeric sequence is consistent with an expected PIN.
Unlike Ghost Overlay, the broader keylogging mechanism does not rely on a transparent keypad overlay. Instead, GhostBat RAT uses Accessibility Service events and UI context to identify and reconstruct PIN-like input across a wider set of targeted financial applications, giving the malware substantially broader coverage within India’s banking and digital payment ecosystem.
The analyzed variant contains a dedicated worker responsible for handling captured PIN information, “PinUploadWorker”. Captured PINS are locally queued before being transmitted to the endpoint “/pin-data”.
Figure 16 – Captured PIN upload activity
The introduction of this capability substantially expands the financial targeting of GhostBat RAT. Earlier variants primarily relied on SMS interception, OTP theft, phishing interfaces, and call-forwarding manipulation.
The new variant can also monitor user interactions within legitimate financial applications and capture PIN-like input via Accessibility Service abuse.
Command and Control Infrastructure
The latest GhostBat RAT variant uses a multi-channel command-and-control architecture that combines a conventional HTTPS backend with Firebase services and a configurable WebSocket tunnel.
Compared with earlier variants, which relied more heavily on hardcoded infrastructure, the new implementation provides greater operational flexibility by allowing the attacker to modify backend addresses and enable or disable selected malware capabilities remotely.
In the analyzed sample, the default C&C infrastructure was configured as hxxps://api[.]cloudsettle[.]org. The malware communicates with this backend via multiple REST API endpoints that handle device registration, SMS collection, call log collection, command acknowledgement, PIN data submission, service state reporting, and other post-compromise functionality.
Endpoint
Purpose
/sms/batch
Uploads batches of SMS messages collected from the infected device
/sms/new
Sends newly received SMS messages to the C&C in near real time
/sms/delivery-status
Reports the delivery or failure status of remotely sent SMS messages
/call-logs/batch
Uploads collected call-log records in bulk
/call-logs/new
Sends newly observed call-log entries to the C&C
/devices/sim-info
Sends SIM and telephony-related information from the infected device
/devices/update-token
Registers or updates the device’s Firebase Cloud Messaging token
/devices/service-status
Reports the operational status of malware services running on the device
/commands/ack
Acknowledges receipt or execution of commands issued by the C&C
/commands/call-forward/status
Reports the result or current state of call-forwarding operations
/ping-response
Responds to C&C ping requests and confirms that the infected device is online
/upload-response
Returns the result or status of generic upload or command operations
/pin-data
Uploads captured PIN-related data, including Ghost Overlay and broader PIN-capture records
/live-keylog/status
Reports or manages the operational state of the live keylogging functionality
One of the major changes in the latest GhostBat RAT variant is the use of Firebase Remote Config as an additional control layer. The analyzed payload is associated with the Firebase project andromeda-d389d and retrieves remotely managed configuration values that control both infrastructure and malware functionality.
Of particular interest is the base_url parameter, which allows the operator to replace the active REST backend without modifying or redistributing the APK. Therefore, api.cloudsettle.org represents the observed/default backend for this sample rather than a permanently fixed C&C address.
Figure 17 – Dynamic C&C implementation
A similar dynamic C&C approach was observed during the GhostX investigation. An earlier NextGen mParivahan sample associated with the ghostx-panel Firebase project retrieved its backend configuration from Firestore using the app_config/network document and the baseUrl field.
In addition to the newly introduced Accessibility Service abuse, Ghost Overlay, targeted PIN capture, and dynamically configurable C&C functionality, GhostBat RAT continues to exhibit several core behaviors documented in our earlier research.
These include collecting SMS messages from compromised devices, monitoring newly received messages for banking- and OTP-related content, stealing UPI credentials through fraudulent mParivahan payment interfaces, and registering compromised devices with attacker-controlled infrastructure.
Earlier GhostBat RAT variants also used Telegram bots for device registration and operator notification, while selected dropper chains contained cryptocurrency-mining functionality alongside the information-stealing payload.
These previously documented capabilities remain important to the overall GhostBat RAT operation; however, the latest variants significantly expand the malware’s financial-theft and remote-control functionality.
Rather than repeating the earlier functionality in detail, this analysis focuses on newly observed capabilities and architectural changes, particularly Accessibility Service abuse, Ghost Overlay PIN interception, broader targeting of financial applications, dynamic Firebase-based configuration, and evolving loader and C2 mechanisms.
Conclusion
The latest GhostBat RAT activity highlights continued evolution across both delivery mechanisms and post-compromise capabilities. The investigation into mParivahan- and eChallan-themed malware exposed the broader GhostX ecosystem, linking phishing infrastructure, backend control, and evolving GhostBat RAT payloads.
The introduction of Accessibility Service abuse, Ghost Overlay, broader PIN capture, and Firebase-driven dynamic configuration significantly expands the malware’s financial-theft capabilities while making the operation more adaptable. Combined with continuously evolving loaders and active phishing activity, GhostBat RAT remains a threat to Android users, particularly across India’s banking, UPI, and digital payment ecosystem.
Cyble’s Threat Intelligence Platformscontinuously monitor emerging threats, infrastructure, and activity across thedark web,deep web, and open sources.This proactive intelligence empowers organizations with early detection, impersonation, infrastructure mapping, and attribution insights. Altogether, these capabilities provide a critical head start in mitigating and responding to evolvingcyber threats.
CRIL’s analysis of this campaign has been selected for the upcoming Association of Anti-Virus Asia Researchers (AVAR) conference, where these findings will be showcased.
Our Recommendations
We have listed essential cybersecurity best practices that form the first line of defense against attackers. We recommend that our readers follow the best practices given below:
Install Apps Only from Trusted Sources: Download apps exclusively from official platforms like the Google Play Store. Avoid third-party app stores or links received via SMS, social media, or email.
Be Cautious with Permissions and Installs: Never grant permissions and install an application unless you’re certain of an app’s legitimacy.
Watch for Phishing Pages: Always verify the URL and avoid suspicious links and websites that ask for sensitive information.
Enable Multi-Factor Authentication (MFA): Use MFA for banking and financial apps to add an extra layer of protection, even if credentials are compromised.
Report Suspicious Activity: If you suspect you’ve been targeted or infected, report the incident to your bank and local authorities immediately. If necessary, reset your credentials and perform a factory reset.
Use Mobile Security Solutions: Install a mobile security application that includes real-time scanning.
Keep Your Device Updated: Ensure your Android OS and apps are updated regularly. Security patches often address vulnerabilities that malware exploits.
MITRE ATT&CK® Techniques
Tactic
Technique ID
Procedure
Initial Access
Phishing (T1660)
GhostBat RAT is distributed through smishing messages containing malicious links that redirect victims to fake mParivahan/eChallan or Google Play-style pages used to deliver the malicious APK.
GhostBat RAT uses a boot-triggered Broadcast Receiver to restart its malicious services and workers after device reboot, allowing the implant to resume background activity.
Defense Evasion
Masquerading: Match Legitimate Name or Location (T1655.001)
GhostBat RAT masquerades as legitimate mParivahan/eChallan applications and uses government-themed names, icons, and interfaces to deceive victims.
Defense Evasion
Obfuscated Files or Information: Software Packing (T1406.002)
GhostBat RAT uses multiple encrypted and packed loader mechanisms, including AES-CBC, XOR, SPKZ/SPK1, encrypted DEX stages, and the libnetbridge.so multi-stage loader to conceal the final payload.
Defense Evasion
Download New Code at Runtime (T1407)
One observed GhostBat RAT delivery variant remotely downloads a second-stage APK, validates the payload, and installs it after the initial dropper executes.
Defense Evasion
Input Injection (T1516)
GhostBat RAT abuses AccessibilityService.dispatchGesture() to replay intercepted PIN-keypad touches into legitimate Google Pay and MobiKwik applications as part of the Ghost Overlay technique.
Credential Access
Abuse Accessibility Features (T1453)
The latest GhostBat RAT variant abuses Android Accessibility Service to monitor targeted financial applications, identify PIN-entry contexts, capture sensitive input, and support Ghost Overlay activity.
Credential Access
Input Capture: Keylogging (T1417.001)
GhostBat RAT uses Accessibility Service events to capture PIN/key-input activity from targeted financial applications. The default configuration targets 60 Android banking, UPI, wallet, fintech, and payment applications.
Credential Access
Input Capture: GUI Input Capture (T1417.002)
Selected GhostBat RAT variants use fraudulent payment interfaces to capture UPI PINs, payment-card details, and other financial information entered by victims.
Credential Access
Access Notifications (T1517)
Selected GhostBat RAT variants register a notification-listener service to monitor notifications generated by other applications, potentially exposing OTPs and other sensitive information.
Discovery
System Information Discovery (T1426)
GhostBat RAT collects device information including Android version, device model, manufacturer, identifiers, and other system metadata.
Discovery
Software Discovery (T1418)
GhostBat RAT can enumerate applications installed on the compromised device and uses package information to identify targeted banking and financial applications.
Collection
Protected User Data: SMS Messages (T1636.004)
GhostBat RAT collects historical SMS messages and monitors newly received messages, including OTPs, banking alerts, and other sensitive message content.
Collection
Protected User Data: Call Log (T1636.002)
GhostBat RAT collects call-history information and uploads historical and newly observed call-log records through its C2 infrastructure.
Impact
SMS Control (T1582)
GhostBat RAT can receive attacker-defined SMS jobs and send messages through the infected device’s SIM, allowing compromised devices to be used for remotely controlled SMS transmission and potentially further smishing activity.
Impact
Call Control (T1616)
GhostBat RAT can manipulate and query call forwarding using USSD-based operations and report the forwarding state to its C2 infrastructure.
Command and Control
Application Layer Protocol: Web Protocols (T1437.001)
GhostBat RAT communicates with its backend through HTTPS REST APIs and uses Firebase Cloud Messaging for command delivery. The latest variant also contains a configurable secure WebSocket communication channel.
Cyble has continued tracking GhostBat RAT activity targeting Android users in India since its initial identification in October 2025. Recent investigations into malicious mParivahan and eChallan-themed applications revealed a broader operator-controlled ecosystem that we track as GhostX.
Analysis of the exposed GhostX backend identified administrative and user-management structures, device-control records, SMS-delivery instructions, call-forwarding activity, and continuously changing phishing content, indicating active campaign management.
Impressions
The latest GhostBat RAT variant represents a significant evolution in both delivery and post-compromise capabilities. The malware now abuses the Android Accessibility Service to support Ghost Overlay and broader PIN/key-input capture targeting financial applications used across India.
Ghost Overlay transparently intercepts PIN keypad interactions in Google Pay and MobiKwik. It replays the same touches into the legitimate application, allowing the malware to capture PIN information without presenting a conventional phishing interface. The variant also targets 60 banking, UPI, wallet, fintech, and payment applications for broader PIN capture.
Modus Operandi
GhostBat RAT has diversified its loader architecture, with at least six observed delivery mechanisms, while the latest build uses libnetbridge.so and multiple cryptographic and custom container stages. Firebase Remote Config further enables operators to dynamically modify C&C infrastructure and malware functionality after installation.
Figure 1 – GhostBat RAT Infection Chain
Key Takeaways
GhostBat RAT continues to target Android users in India via mParivahan- and eChallan-themed smishing campaigns, using phishing pages and public hosting platforms to distribute malicious APKs.
Our investigation uncovered GhostX, a broader operator-controlled ecosystem that supports phishing, device management, backend configuration, and the distribution of the GhostBat RAT.
The latest GhostBat RAT variant abuses the Android Accessibility Service, including the Ghost Overlay technique to intercept PIN entry in legitimate Google Pay and MobiKwik applications.
The malware also implements broader PIN/key-input capture targeting 60 Android applications associated with India’s banking, UPI, wallet, fintech, and digital-payment ecosystem.
GhostBat RAT’s delivery layer has evolved through multiple loader and dropper implementations, with the latest libnetbridge.so loader employing several transformations, including encryption, compression, and custom container stages, before recovering the final payload.
Firebase Remote Config enables dynamic C&C and feature management, allowing operators to modify backend infrastructure and selected malware capabilities without rebuilding or redistributing the APK.
Overview
In October 2025, Cyble identified GhostBat RAT being distributed through MiningDropper and targeting Android users in India.
We have since continued to track related activity and investigate malicious applications impersonating India’s mParivahan and eChallan services. This research uncovered a broader Android threat ecosystem that we track as GhostX, along with significantly evolved variants of GhostBat RAT.
The most recent GhostBat RAT variant demonstrates a notable increase in capability and operational flexibility. It uses Firebase Remote Config to dynamically manage command-and-control (C&C) infrastructure and to enable or disable individual malware modules without requiring APK redistribution.
This variant also implements a sophisticated Ghost Overlay technique targeting legitimate Google Pay and MobiKwik PIN-entry interfaces. Instead of displaying a conventional fake login page, the malware places transparent accessibility overlays over the legitimate application’s keypad, records the victim’s touch selections, and replays the same interaction into the genuine application.
Additionally, the malware implements a PIN-capture capability through keylogging, targeting 60 Android applications across India’s banking, UPI, wallet, fintech, and digital payment ecosystem.
The malware’s delivery and packing mechanisms have evolved considerably across the samples analyzed. We identified at least six distinct loader or dropper implementations, including:
Native AES-CBC-protected APK containers
Custom SPKZ/SPK1 payload formats
Java-based in-memory DEX loaders
Remote APK downloaders
Multi-stage XOR/AES loaders
A newer native libnetbridge.so loader using multiple cryptographic, transformation, compression, and custom container stages before recovering the final payload
This diversification suggests continued investment in defeating static detection and complicating automated malware extraction.
GhostBat RAT is primarily distributed via smishing messages that contain malicious links. When victims follow these links, they are redirected to phishing pages that impersonate either the legitimate Parivahan service or a Google Play-style application download page and are encouraged to install a fraudulent mParivahan APK (see Figures 2 and 3).
During our investigation, we also repeatedly observed GitHub repositories and GitHub-hosted assets being used to distribute malicious APKs, providing attackers with readily available public hosting infrastructure.
Figure 2 – Fake Google Play Store-style mParivahan installation websiteFigure 3 – Fake mParivahan website prompting to download APK file
Discovery of the GhostX Ecosystem
The GhostX investigation began with the discovery of multiple Android applications impersonating India’s mParivahan and eChallan ecosystem.
Samples were collected from phishing infrastructure and public GitHub repositories containing APKs named or presented as mParivahan, vehicle-challan, traffic-enforcement, or other related government applications.
Initial static analysis revealed that many of these APKs were only first-stage loaders. Their visible DEX code offered limited functionality, while the actual malware payload was either concealed within encrypted assets or retrieved later.
After unpacking the applications to their final payloads, we identified multiple custom C&C infrastructures, Firebase projects, and overlapping Android surveillance and financial-fraud capabilities.
A major breakthrough came from the analysis of a NextGen mParivahan sample whose unpacked payload contained the Firebase project identifier:
ghostx-panel
The exposed Firebase backend provided significantly greater visibility into the operator’s infrastructure and control workflow. The database contained structures including:
clients
bot_users
admins
admin_logins
settings
All_Users
Verify_Device
Analysis of the exposed GhostX backend revealed evidence of a structured operator-management layer beyond conventional malware C&C functionality.
The database contained administrator and user records with role and account-status fields, a global session identifier, bot-user mappings, and dedicated admin_logins records containing device fingerprints, timestamps, and online status (see Figure 4).
These artifacts indicate that GhostX incorporates an authentication and session management framework for operator-side access and management of compromised devices.
The presence of distinct user, administrator, and bot-user roles suggests a multi-operator, service-oriented architecture. It raises the possibility that GhostX could support a Malware-as-a-Service-style operating model.
Figure 4 – Exposed administrative records.
During continued monitoring of the exposed infrastructure, we observed that SMS lure content, phishing URLs, vehicle registration numbers, and recipient phone numbers were repeatedly changing, indicating active operator-side campaign management rather than a static or abandoned database (see Figure 5).
Similar eChallan-themed messages were also observed being received by users in the wild, further supporting the campaign’s operational nature (see Figure 6).
Figure 5 – Exposed SMS message configured to be sent to victimsFigure 6 – Same SMSs are being received by the victims (Source – Twitter Post)
One of the phishing URLs exposed through the GhostX infrastructure subsequently led us to a previously unseen GhostBat RAT variant, providing a direct investigative link among the backend control ecosystem, active phishing operations, and the malware’s continued evolution.
These findings led us to assess that GhostX is not a single Android malware family or standalone application. Instead, GhostX represents a broader operator-controlled ecosystem encompassing phishing infrastructure, backend services, Firebase-based configuration and command mechanisms, device-management functionality, and malware distribution.
GhostBat RAT represents the Android implant operating within this ecosystem, with individual variants continuing to evolve across both delivery mechanisms and post-compromise capabilities.
Technical Analysis
Evolution of Droppers and Loaders
GhostBat RAT has undergone continuous changes in its delivery and payload-protection mechanisms.
Across the samples analyzed during the GhostX investigation, we identified multiple loader and dropper implementations designed to conceal the underlying malware payload, complicate static analysis, and reduce the effectiveness of hash- and signature-based detection.
Although the recovered payloads demonstrate overlapping capabilities for surveillance, financial theft, and device control, the mechanisms used to deliver and recover them vary considerably across samples.
Earlier variants relied on comparatively straightforward native loaders that decrypted embedded APK payloads using AES-CBC. Subsequent variants of Ghostbat RAT introduced XOR-encrypted custom containers, SPKZ/SPK1 packaging, split-APK delivery, dynamically loaded DEX components, and Java-based in-memory loaders.
One variant moved away from embedded payload delivery entirely. It operated as a remote downloader, retrieving a second-stage APK from remote infrastructure, validating its SHA-256 hash, and installing it through Android’s package installation framework.
The most recent variant analyzed introduces a substantially more complex native loader implemented in libnetbridge.so. This loader combines multiple transformations, encryption, compression, and custom container stages before recovering the final GhostBat RAT payload.
This diversification indicates continued modification of the delivery layer while broadly retaining the malware’s post-compromise objectives. Consequently, detections that focus only on the outer APK, the encrypted asset name, or a single unpacking routine are unlikely to provide durable coverage.
The GhostBat RAT loaders/droppers variants we observed are listed below:
Figure 7 – GhostBat RAT Loader variants
The most recent GhostBat RAT sample introduced a significantly more complex native unpacking mechanism.
Unlike earlier variants that relied primarily on Java-based loaders or comparatively straightforward XOR/AES routines, this variant stores the encrypted payload inside an opaque application asset, assets/isti52q4, while most of the unpacking logic is implemented in the native library libnetbridge.so.
The visible application code does not directly expose the final malicious functionality. Instead, execution transitions to the native loader, which processes the embedded asset through several sequential stages of transformation and decryption (see Figure 8).
Figure 8 – Latest native dropper unpacking chain
The first stage processes content within the encrypted asset file and derives values required for subsequent decoding. The resulting data is then passed through an RC4-like transformation before being processed through AES-256-GCM. This layered approach prevents the encrypted asset from being recovered using simple XOR or direct AES key extraction techniques that worked against earlier GhostBat RAT loaders.
Following successful decryption, the loader recovers an MSZ1-formatted intermediate object that is decompressed using zlib. The decompressed data contains an MSP1 container that packages the final Android application components.
The recovered payload consists of a split-APK application, including base.apk and split_config.dex.apk.
The executable malware code is primarily contained within the recovered split configuration DEX.
Unlike earlier samples, where the encrypted payload could be identified directly from ZIP headers or standard APK structures, the latest loader hides the final application behind several custom transformations before any recognizable Android package becomes available.
This significantly increases the effort required for automated unpacking and reduces the effectiveness of simple asset-scanning techniques.
Advanced GhostBat RAT Payload
GhostBat RAT has evolved from an Android SMS and information stealer into a modular remote-access and Banking Trojan.
Across the analyzed variants, the malware demonstrates capabilities for device profiling, SMS interception, remote SMS transmission, call-forwarding manipulation, payment-data theft, accessibility-based PIN capture, Firebase-driven command delivery, dynamic C&C configuration, and remote tunnelling.
In the new GhostBat RAT variant, we observed the introduction of Android Accessibility Service abuse, a technique commonly associated with modern Android Banking Trojans.
Earlier GhostBat RAT variants that we analyzed did not possess these capabilities during this investigation. The new variant uses Accessibility Service to monitor foreground applications, identify PIN-entry contexts, interact with application interfaces, and support two distinct credential-theft mechanisms: Ghost Overlay and targeted PIN/key-input capture.
Once Accessibility Services access is granted, the malware monitors the foreground application and compares it against configured target lists. These targets can be managed through Firebase Remote Config, allowing operators to selectively activate credential-capture functionality when a targeted banking, UPI, wallet, or payment application is in use.
Ghost Overlay
The most notable capability introduced in this variant is the Ghost Overlay technique.
Figure 9.1 – Ghost Overlay Attack Flow
Unlike conventional Android overlay attacks that display a fake login or payment page over the legitimate application, GhostBat RAT does not need to replace the victim’s banking interface. Instead, it places transparent accessibility overlay regions directly over the real PIN keypad displayed by the targeted application.
The feature is controlled through Firebase Remote Config using:
The default Ghost Overlay configuration targets the following Android packages:
com.mobikwik_new
com.google.android.apps.nbu.paisa
com.google.android.apps.nbu.paisa.user
Figure 10 – Target package list of Ghost Overlay activity
When the malware detects one of these applications in the foreground and identifies a PIN-related activity, it creates a transparent keypad grid using Android’s TYPE_ACCESSIBILITY_OVERLAY. The overlay contains 12 touch regions matching the layout of a typical numeric PIN pad (see Figures 11 and 12):
When the victim taps a digit on the legitimate Google Pay or MobiKwik PIN keypad, the transparent Ghost Overlay intercepts the touch event before it reaches the underlying application.
The malware maps the touch coordinates to the corresponding keypad value and appends the resulting digit to an internal buffer used to reconstruct the PIN.
To avoid interrupting the payment flow or alerting the victim, GhostBat RAT temporarily releases the affected overlay region and uses AccessibilityService.dispatchGesture() to reproduce the same tap at the corresponding screen coordinates (see Figure 13).
As a result, the legitimate application receives the expected input and continues operating normally, while the malware records the victim’s PIN in parallel.
The same mechanism handles DEL and OK interactions, allowing the GhostBat RAT to update the captured digit sequence and detect when the PIN entry process has completed. This intercept-and-replay behavior enables the malware to observe PIN entry without presenting a fake Google Pay or MobiKwik interface.
Figure 13 – dispatchGesture activity
Once collected, the PIN is stored with metadata identifying the capture source as ghost_overlay and is subsequently queued for exfiltration over C&C “hxxps://api.cloudsettle[.]org/pin-data” (see Figure 14).
Figure 14 – Storing captured Ghost PIN
This technique is considerably stealthier than a conventional phishing overlay because the victim remains within the genuine financial application’s interface throughout the interaction. GhostBat RAT effectively operates as an invisible intermediary, intercepting the victim’s keypad interaction, recording the selected digits, and replaying those same touches into the legitimate application in near real time.
Targeted Keylogging and PIN Capture
In addition to the Ghost Overlay capability, the new GhostBat RAT variant implements a broader accessibility-based PIN/key-input capture mechanism targeting applications across India’s banking, UPI, wallet, fintech, and digital-payment ecosystem.
Unlike the Ghost Overlay feature, which is specifically designed to intercept keypad touches in Google Pay and MobiKwik via transparent overlay regions, this functionality relies on Android Accessibility Service events to monitor user interactions across a much larger set of targeted applications.
The default pin_target_packages configuration includes 60 Android package identifiers for financial applications used across India (see Figure 15).
The target set includes applications associated with Google Pay, PhonePe, Paytm, MobiKwik, BHIM, SBI UPI, Axis Pay, BharatPe, CRED, Freecharge, PayZapp, Groww, Navi, Jupiter, OneCard, JioFinance, Samsung Pay, and several other banking and payment services. The complete list of targeted Android packages is provided in the Targeted Application List section.
Once Accessibility Service is granted, GhostBat RAT monitors foreground activity and determines whether the currently running application(s) match an entry in pin_target_packages. The malware then evaluates the surrounding application and screen context before treating observed numeric input as potentially sensitive PIN information.
Figure 15 – PIN target package list
The malware also uses configurable PIN-length boundaries, pin_min_digits, and pin_min_digits to determine whether the reconstructed numeric sequence is consistent with an expected PIN.
Unlike Ghost Overlay, the broader keylogging mechanism does not rely on a transparent keypad overlay. Instead, GhostBat RAT uses Accessibility Service events and UI context to identify and reconstruct PIN-like input across a wider set of targeted financial applications, giving the malware substantially broader coverage within India’s banking and digital payment ecosystem.
The analyzed variant contains a dedicated worker responsible for handling captured PIN information, “PinUploadWorker”. Captured PINS are locally queued before being transmitted to the endpoint “/pin-data”.
Figure 16 – Captured PIN upload activity
The introduction of this capability substantially expands the financial targeting of GhostBat RAT. Earlier variants primarily relied on SMS interception, OTP theft, phishing interfaces, and call-forwarding manipulation.
The new variant can also monitor user interactions within legitimate financial applications and capture PIN-like input via Accessibility Service abuse.
Command and Control Infrastructure
The latest GhostBat RAT variant uses a multi-channel command-and-control architecture that combines a conventional HTTPS backend with Firebase services and a configurable WebSocket tunnel.
Compared with earlier variants, which relied more heavily on hardcoded infrastructure, the new implementation provides greater operational flexibility by allowing the attacker to modify backend addresses and enable or disable selected malware capabilities remotely.
In the analyzed sample, the default C&C infrastructure was configured as hxxps://api[.]cloudsettle[.]org. The malware communicates with this backend via multiple REST API endpoints that handle device registration, SMS collection, call log collection, command acknowledgement, PIN data submission, service state reporting, and other post-compromise functionality.
Endpoint
Purpose
/sms/batch
Uploads batches of SMS messages collected from the infected device
/sms/new
Sends newly received SMS messages to the C&C in near real time
/sms/delivery-status
Reports the delivery or failure status of remotely sent SMS messages
/call-logs/batch
Uploads collected call-log records in bulk
/call-logs/new
Sends newly observed call-log entries to the C&C
/devices/sim-info
Sends SIM and telephony-related information from the infected device
/devices/update-token
Registers or updates the device’s Firebase Cloud Messaging token
/devices/service-status
Reports the operational status of malware services running on the device
/commands/ack
Acknowledges receipt or execution of commands issued by the C&C
/commands/call-forward/status
Reports the result or current state of call-forwarding operations
/ping-response
Responds to C&C ping requests and confirms that the infected device is online
/upload-response
Returns the result or status of generic upload or command operations
/pin-data
Uploads captured PIN-related data, including Ghost Overlay and broader PIN-capture records
/live-keylog/status
Reports or manages the operational state of the live keylogging functionality
One of the major changes in the latest GhostBat RAT variant is the use of Firebase Remote Config as an additional control layer. The analyzed payload is associated with the Firebase project andromeda-d389d and retrieves remotely managed configuration values that control both infrastructure and malware functionality.
Of particular interest is the base_url parameter, which allows the operator to replace the active REST backend without modifying or redistributing the APK. Therefore, api.cloudsettle.org represents the observed/default backend for this sample rather than a permanently fixed C&C address.
Figure 17 – Dynamic C&C implementation
A similar dynamic C&C approach was observed during the GhostX investigation. An earlier NextGen mParivahan sample associated with the ghostx-panel Firebase project retrieved its backend configuration from Firestore using the app_config/network document and the baseUrl field.
In addition to the newly introduced Accessibility Service abuse, Ghost Overlay, targeted PIN capture, and dynamically configurable C&C functionality, GhostBat RAT continues to exhibit several core behaviors documented in our earlier research.
These include collecting SMS messages from compromised devices, monitoring newly received messages for banking- and OTP-related content, stealing UPI credentials through fraudulent mParivahan payment interfaces, and registering compromised devices with attacker-controlled infrastructure.
Earlier GhostBat RAT variants also used Telegram bots for device registration and operator notification, while selected dropper chains contained cryptocurrency-mining functionality alongside the information-stealing payload.
These previously documented capabilities remain important to the overall GhostBat RAT operation; however, the latest variants significantly expand the malware’s financial-theft and remote-control functionality.
Rather than repeating the earlier functionality in detail, this analysis focuses on newly observed capabilities and architectural changes, particularly Accessibility Service abuse, Ghost Overlay PIN interception, broader targeting of financial applications, dynamic Firebase-based configuration, and evolving loader and C2 mechanisms.
Conclusion
The latest GhostBat RAT activity highlights continued evolution across both delivery mechanisms and post-compromise capabilities. The investigation into mParivahan- and eChallan-themed malware exposed the broader GhostX ecosystem, linking phishing infrastructure, backend control, and evolving GhostBat RAT payloads.
The introduction of Accessibility Service abuse, Ghost Overlay, broader PIN capture, and Firebase-driven dynamic configuration significantly expands the malware’s financial-theft capabilities while making the operation more adaptable. Combined with continuously evolving loaders and active phishing activity, GhostBat RAT remains a threat to Android users, particularly across India’s banking, UPI, and digital payment ecosystem.
Cyble’s Threat Intelligence Platformscontinuously monitor emerging threats, infrastructure, and activity across thedark web,deep web, and open sources.This proactive intelligence empowers organizations with early detection, impersonation, infrastructure mapping, and attribution insights. Altogether, these capabilities provide a critical head start in mitigating and responding to evolvingcyber threats.
CRIL’s analysis of this campaign has been selected for the upcoming Association of Anti-Virus Asia Researchers (AVAR) conference, where these findings will be showcased.
Our Recommendations
We have listed essential cybersecurity best practices that form the first line of defense against attackers. We recommend that our readers follow the best practices given below:
Install Apps Only from Trusted Sources: Download apps exclusively from official platforms like the Google Play Store. Avoid third-party app stores or links received via SMS, social media, or email.
Be Cautious with Permissions and Installs: Never grant permissions and install an application unless you’re certain of an app’s legitimacy.
Watch for Phishing Pages: Always verify the URL and avoid suspicious links and websites that ask for sensitive information.
Enable Multi-Factor Authentication (MFA): Use MFA for banking and financial apps to add an extra layer of protection, even if credentials are compromised.
Report Suspicious Activity: If you suspect you’ve been targeted or infected, report the incident to your bank and local authorities immediately. If necessary, reset your credentials and perform a factory reset.
Use Mobile Security Solutions: Install a mobile security application that includes real-time scanning.
Keep Your Device Updated: Ensure your Android OS and apps are updated regularly. Security patches often address vulnerabilities that malware exploits.
MITRE ATT&CK® Techniques
Tactic
Technique ID
Procedure
Initial Access
Phishing (T1660)
GhostBat RAT is distributed through smishing messages containing malicious links that redirect victims to fake mParivahan/eChallan or Google Play-style pages used to deliver the malicious APK.
GhostBat RAT uses a boot-triggered Broadcast Receiver to restart its malicious services and workers after device reboot, allowing the implant to resume background activity.
Defense Evasion
Masquerading: Match Legitimate Name or Location (T1655.001)
GhostBat RAT masquerades as legitimate mParivahan/eChallan applications and uses government-themed names, icons, and interfaces to deceive victims.
Defense Evasion
Obfuscated Files or Information: Software Packing (T1406.002)
GhostBat RAT uses multiple encrypted and packed loader mechanisms, including AES-CBC, XOR, SPKZ/SPK1, encrypted DEX stages, and the libnetbridge.so multi-stage loader to conceal the final payload.
Defense Evasion
Download New Code at Runtime (T1407)
One observed GhostBat RAT delivery variant remotely downloads a second-stage APK, validates the payload, and installs it after the initial dropper executes.
Defense Evasion
Input Injection (T1516)
GhostBat RAT abuses AccessibilityService.dispatchGesture() to replay intercepted PIN-keypad touches into legitimate Google Pay and MobiKwik applications as part of the Ghost Overlay technique.
Credential Access
Abuse Accessibility Features (T1453)
The latest GhostBat RAT variant abuses Android Accessibility Service to monitor targeted financial applications, identify PIN-entry contexts, capture sensitive input, and support Ghost Overlay activity.
Credential Access
Input Capture: Keylogging (T1417.001)
GhostBat RAT uses Accessibility Service events to capture PIN/key-input activity from targeted financial applications. The default configuration targets 60 Android banking, UPI, wallet, fintech, and payment applications.
Credential Access
Input Capture: GUI Input Capture (T1417.002)
Selected GhostBat RAT variants use fraudulent payment interfaces to capture UPI PINs, payment-card details, and other financial information entered by victims.
Credential Access
Access Notifications (T1517)
Selected GhostBat RAT variants register a notification-listener service to monitor notifications generated by other applications, potentially exposing OTPs and other sensitive information.
Discovery
System Information Discovery (T1426)
GhostBat RAT collects device information including Android version, device model, manufacturer, identifiers, and other system metadata.
Discovery
Software Discovery (T1418)
GhostBat RAT can enumerate applications installed on the compromised device and uses package information to identify targeted banking and financial applications.
Collection
Protected User Data: SMS Messages (T1636.004)
GhostBat RAT collects historical SMS messages and monitors newly received messages, including OTPs, banking alerts, and other sensitive message content.
Collection
Protected User Data: Call Log (T1636.002)
GhostBat RAT collects call-history information and uploads historical and newly observed call-log records through its C2 infrastructure.
Impact
SMS Control (T1582)
GhostBat RAT can receive attacker-defined SMS jobs and send messages through the infected device’s SIM, allowing compromised devices to be used for remotely controlled SMS transmission and potentially further smishing activity.
Impact
Call Control (T1616)
GhostBat RAT can manipulate and query call forwarding using USSD-based operations and report the forwarding state to its C2 infrastructure.
Command and Control
Application Layer Protocol: Web Protocols (T1437.001)
GhostBat RAT communicates with its backend through HTTPS REST APIs and uses Firebase Cloud Messaging for command delivery. The latest variant also contains a configurable secure WebSocket communication channel.
Disclaimer: This blog is based on publicly available information, including a police report and posts shared on X, as of October 13, 2026. Cyble has not independently verified these claims. The allegations remain unproven, and naming any organization does not imply its involvement. This content is for informational purposes only and is not legal or financial advice.
A crypto security event that promised to teach attendees how to avoid scams is now the subject of scam allegations. The gathering, branded “Don’t Get Played,” was held as a side event during TOKEN2049 week in Singapore and co-hosted by groups operating under the names “Apex Accelerator” and “Stone Venture.”
According to a police report filed by one attendee with the Singapore Police Force, the organizers allegedly pressured guests to install software that would have handed the organizers remote control of their computers.
The allegation first gained traction on X, where several other users claimed they had also been approached by the same group.
What the “Don’t Get Played” Police Report States
The document circulating online is page two of a six-page Singapore Police Force report (form NP299), bearing reference number E/20261011/7004. In it, the complainant lists the group’s website as token.apexaccs.org and notes that the event’s Telegram group had no public URL; prospective attendees could only join through the website.
Report filed to the Singapore Police (Source: SolanaFloor on X)
The report is titled “Suspected cyber scam targeting TOKEN2049 attendees (‘Don’t Get Played’ event).” Its summary reads:
“A group using the names ‘Apex Accelerator’, ‘Stone Venture’ and ‘Don’t Get Played’ promoted a crypto security event for TOKEN2049 week (Sun 11 Oct 2026, 6pm to 10pm, The Singapore EDITION). They pressured attendees to install software that would give them remote control of their computers. I did not install their software and have no financial loss.”
Two details in that statement matter. First, the person who filed the report says they did not install anything. Second, they report no financial loss. The filing therefore documents an alleged attempt rather than a confirmed compromise.
How the TOKEN2049 Side Event Was Pitched
On paper, “Don’t Get Played” looked like exactly the kind of session a careful attendee would seek out. It was marketed as a security-focused gathering designed to help people protect themselves from token scams.
“Don’t Get Played” registration page (Source: Defraud on X)
The event was scheduled for The Singapore EDITION hotel in early October 2026. Entry was free, though guests had to register beforehand, and attendance was capped at 200 people, as detailed by Crypto Briefing.
The agenda featured a live “wallet clinic” where attendees could have their holdings checked with “Apex Audit” tools. These were promoted as scanners for token risk and honeypots, a term for tokens engineered so that holders can buy them but are never able to sell.
The promotional material also advertised a panel on how crypto scams have evolved, listing representatives from Spartan Group, Bybit’s security team, and the Singapore Police Force Cyber Command among the speakers.
The final hook was a giveaway. Every confirmed guest was promised a free year of Sophos MDR endpoint protection, bundled with up to $1 million in breach coverage. Research into the event suggests this offer was a major driver of interest.
There is nothing in the available material indicating that Spartan Group, Bybit, Sophos, or the Singapore Police Force Cyber Command played any part in the alleged conduct. Their names appeared in the event promotion, and that is the full extent of what the sources establish.
The Allegation and the Gaps in the Record
The central claim is simple: organizers of “Don’t Get Played” allegedly pushed attendees to install software that would give a third-party remote access to their machines. At a crypto event, where many guests carry laptops connected to wallets and exchange accounts, that level of access could be enough to empty funds.
Several important facts remain unclear. The source material does not name the software attendees were allegedly asked to install. It does not state whether anyone lost money, and it does not say how many people may have been targeted.
As of October 12, 2026, no mainstream coverage of a police report involving the organizers, or of complaints from victims, could be located. The Singapore Police Force has not publicly confirmed the filing. Apex Accelerator and Stone Venture have not been charged with any offense based on the information available, and their account of events has not yet entered the public record.
How the Crypto Community Reacted to “Don’t Get Played”?
After SolanaFloor shared the police report on X, the replies split between people claiming firsthand contact, skeptics, and users offering security advice. The account 0xKYM Registry (@KYMRegistrySG) said it filed the report and shared what it described as a scan of the installation’s contents.
Several others, including FamCrypt (@Famous0x3), NomadFury (@NomadFury_), and Sabya | YeNo (@SabyaYeNo), said the group had approached or pressured them to install software or buy a subscription. Alex (@alwye) claimed Apex Accelerator had used similar tactics in Twitter DMs.
Reactions on Don’t Get Played (Source: X)
Not everyone was convinced. Sprunky (@sprunky_eth) argued that “page 2 of a report is not a finding,” noting the complainant lost nothing, SPF had not confirmed the filing, and no charges exist. Others questioned how anyone could be pressured in Singapore or who vetted the project for the TOKEN2049 lineup.
Security-minded users focused on the risk. StakeCraft (@stakecraft) called remote laptop access at a crypto event “a wallet drain waiting to happen,” and Jey (@TheWarKettle) advised anyone who installed the software to treat the device as compromised, move funds from a clean device, and rotate every password and key.
Others pointed to fake Luma after-party links and similar incidents at other conferences, and one user floated an unsupported DPRK link. Many replies also mocked the irony of a security event called “Don’t Get Played” allegedly becoming the play.
Conclusion
The “Don’t Get Played” allegations rest on a single attendee’s police report and a growing set of claims on X, none of which have been confirmed by authorities. Several questions remain open.
Will Singapore authorities confirm that a report was filed? Will Apex Accelerator or Stone Venture respond publicly? And will Spartan Group or the Singapore Police Force Cyber Command clarify whether they had any connection to the event? Until those answers arrive, the safest assumption for attendees is the one the event’s own name suggested: any request to install software deserves suspicion.
Disclaimer: This blog is based on publicly available information, including a police report and posts shared on X, as of October 13, 2026. Cyble has not independently verified these claims. The allegations remain unproven, and naming any organization does not imply its involvement. This content is for informational purposes only and is not legal or financial advice.
A crypto security event that promised to teach attendees how to avoid scams is now the subject of scam allegations. The gathering, branded “Don’t Get Played,” was held as a side event during TOKEN2049 week in Singapore and co-hosted by groups operating under the names “Apex Accelerator” and “Stone Venture.”
According to a police report filed by one attendee with the Singapore Police Force, the organizers allegedly pressured guests to install software that would have handed the organizers remote control of their computers.
The allegation first gained traction on X, where several other users claimed they had also been approached by the same group.
What the “Don’t Get Played” Police Report States
The document circulating online is page two of a six-page Singapore Police Force report (form NP299), bearing reference number E/20261011/7004. In it, the complainant lists the group’s website as token.apexaccs.org and notes that the event’s Telegram group had no public URL; prospective attendees could only join through the website.
Report filed to the Singapore Police (Source: SolanaFloor on X)
The report is titled “Suspected cyber scam targeting TOKEN2049 attendees (‘Don’t Get Played’ event).” Its summary reads:
“A group using the names ‘Apex Accelerator’, ‘Stone Venture’ and ‘Don’t Get Played’ promoted a crypto security event for TOKEN2049 week (Sun 11 Oct 2026, 6pm to 10pm, The Singapore EDITION). They pressured attendees to install software that would give them remote control of their computers. I did not install their software and have no financial loss.”
Two details in that statement matter. First, the person who filed the report says they did not install anything. Second, they report no financial loss. The filing therefore documents an alleged attempt rather than a confirmed compromise.
How the TOKEN2049 Side Event Was Pitched
On paper, “Don’t Get Played” looked like exactly the kind of session a careful attendee would seek out. It was marketed as a security-focused gathering designed to help people protect themselves from token scams.
“Don’t Get Played” registration page (Source: Defraud on X)
The event was scheduled for The Singapore EDITION hotel in early October 2026. Entry was free, though guests had to register beforehand, and attendance was capped at 200 people, as detailed by Crypto Briefing.
The agenda featured a live “wallet clinic” where attendees could have their holdings checked with “Apex Audit” tools. These were promoted as scanners for token risk and honeypots, a term for tokens engineered so that holders can buy them but are never able to sell.
The promotional material also advertised a panel on how crypto scams have evolved, listing representatives from Spartan Group, Bybit’s security team, and the Singapore Police Force Cyber Command among the speakers.
The final hook was a giveaway. Every confirmed guest was promised a free year of Sophos MDR endpoint protection, bundled with up to $1 million in breach coverage. Research into the event suggests this offer was a major driver of interest.
There is nothing in the available material indicating that Spartan Group, Bybit, Sophos, or the Singapore Police Force Cyber Command played any part in the alleged conduct. Their names appeared in the event promotion, and that is the full extent of what the sources establish.
The Allegation and the Gaps in the Record
The central claim is simple: organizers of “Don’t Get Played” allegedly pushed attendees to install software that would give a third-party remote access to their machines. At a crypto event, where many guests carry laptops connected to wallets and exchange accounts, that level of access could be enough to empty funds.
Several important facts remain unclear. The source material does not name the software attendees were allegedly asked to install. It does not state whether anyone lost money, and it does not say how many people may have been targeted.
As of October 12, 2026, no mainstream coverage of a police report involving the organizers, or of complaints from victims, could be located. The Singapore Police Force has not publicly confirmed the filing. Apex Accelerator and Stone Venture have not been charged with any offense based on the information available, and their account of events has not yet entered the public record.
How the Crypto Community Reacted to “Don’t Get Played”?
After SolanaFloor shared the police report on X, the replies split between people claiming firsthand contact, skeptics, and users offering security advice. The account 0xKYM Registry (@KYMRegistrySG) said it filed the report and shared what it described as a scan of the installation’s contents.
Several others, including FamCrypt (@Famous0x3), NomadFury (@NomadFury_), and Sabya | YeNo (@SabyaYeNo), said the group had approached or pressured them to install software or buy a subscription. Alex (@alwye) claimed Apex Accelerator had used similar tactics in Twitter DMs.
Reactions on Don’t Get Played (Source: X)
Not everyone was convinced. Sprunky (@sprunky_eth) argued that “page 2 of a report is not a finding,” noting the complainant lost nothing, SPF had not confirmed the filing, and no charges exist. Others questioned how anyone could be pressured in Singapore or who vetted the project for the TOKEN2049 lineup.
Security-minded users focused on the risk. StakeCraft (@stakecraft) called remote laptop access at a crypto event “a wallet drain waiting to happen,” and Jey (@TheWarKettle) advised anyone who installed the software to treat the device as compromised, move funds from a clean device, and rotate every password and key.
Others pointed to fake Luma after-party links and similar incidents at other conferences, and one user floated an unsupported DPRK link. Many replies also mocked the irony of a security event called “Don’t Get Played” allegedly becoming the play.
Conclusion
The “Don’t Get Played” allegations rest on a single attendee’s police report and a growing set of claims on X, none of which have been confirmed by authorities. Several questions remain open.
Will Singapore authorities confirm that a report was filed? Will Apex Accelerator or Stone Venture respond publicly? And will Spartan Group or the Singapore Police Force Cyber Command clarify whether they had any connection to the event? Until those answers arrive, the safest assumption for attendees is the one the event’s own name suggested: any request to install software deserves suspicion.
Disclaimer: This blog is based on publicly available information, including a police report and posts shared on X, as of October 13, 2026. Cyble has not independently verified these claims. The allegations remain unproven, and naming any organization does not imply its involvement. This content is for informational purposes only and is not legal or financial advice.
