Banking malware just got a serious upgrade in how it hides itself from security teams. A campaign built around Banana RAT, a remote access trojan long tied to Brazilian banking fraud, has been caught using an exposed backend server that builds new malware variants on demand.
That server did not just host malicious files; it ran active tooling capable of generating fresh, differently disguised payloads whenever an attacker needed one.
Researcher Moises Cerqueira’s discovery began with a public index found on a single IP address, exposed and searchable through routine internet scanning.
Instead of a static malware sample, researchers found a working delivery platform, complete with a payload generator and an obfuscation script sitting next to the malicious files themselves.
Comparing the two side by side gave a detailed look at how a banking trojan operator refines evasion techniques in near real time.
That matters for anyone building detection rules or trying to block this activity before it reaches a victim’s banking session.
Banana RAT targets financial activity directly, focusing on stealing banking credentials and interfering with payment transactions. Its ability to regenerate itself in new forms makes blocklist-based defenses far less reliable over time.
Banana RAT Uses Exposed Payload Generator
The exposed server ran a script called servidor_completo_pool.py, a backend service built to pre-generate malware payloads in batches rather than one at a time.
It pulled source files from a web directory and offered several web addresses that let it warm up payload pools, report statistics, and serve finished files.
This points to a builder designed for ongoing production of new malware copies rather than a single static file left online by mistake.
Sitting alongside it was a second script, ofuscador.py, which took plain PowerShell commands and rewrote them into a scrambled character sequence reassembled and run at execution time.
That trick, shown in Figure Name: Exposed public index at 198.245.53.26, is what let the same base malware look different every time it landed on a new machine, since surface details keep changing while underlying behavior stays consistent.
How the Two Banana RAT Branches Differ
The earlier version, detonated in late May, relied on fixed file names and folder paths designed to look like legitimate Windows update components.
It used a lookalike domain with a spelling error, a detail that made it easier to spot once defenders noticed the mismatch. Persistence relied on a scheduled task tied to a named executable, giving analysts a stable fingerprint to track.
The newer version, seen in early June, dropped that predictable structure entirely. Installation folders and file names are now generated randomly for each infected machine, and persistence shifts to a VBS launcher paired with a hidden scheduled task running with system-level privileges.
Communication with attacker servers happens over an encrypted WebSocket channel, using an address built from a hashed identifier unique to each infected computer, making simple domain blocking far less effective.
One detail stayed constant across both versions: a fallback IP address embedded in the code, linking the newer branch directly back to the older infrastructure.
Security teams are encouraged to block traffic tied to the known indicators below, monitor for scheduled tasks created under suspicious names, and treat unexpected hidden PowerShell activity as a warning sign worth investigating.
Tracking both branches through the same exposed infrastructure gave defenders a clearer view of how this malware family keeps adapting.
Indicators of compromise (IoCs):-
| Type | Indicator | Description |
|---|---|---|
| IP | 198[.]245[.]53[.]26 | Exposed staging server hosting payload generator and obfuscation scripts |
| IP | 149[.]56[.]12[.]51 | Fallback C2 IP shared across both older and newer Banana RAT branches |
| IP | 104[.]21.39.172 | Cloudflare edge IP resolved for newer branch WebSocket C2 domain |
| IP | 67[.]142[.]55 | Cloudflare edge IP resolved for newer branch WebSocket C2 domain |
| Domain | c.windowns-cdn.com | Pseudo-Microsoft C2 domain used by the older detonation branch |
| Domain | testewin.com | Base apex domain used for newer branch’s hashed WebSocket C2 subdomains |
| Domain | 52facc3b24f8bad9c5c56819e385f3a1.testewin.com | Host-derived C2 subdomain resolved during newer branch detonation |
| Domain | cdn.testewin.com | Fallback domain embedded in newer branch runtime payload |
| File | Fatura-BtgPactual-22568.bat | Older detonation entry sample (SHA256: BC4C29BC0C84EA18311FBADC508F6F3A9D84B54AAB34D6B42F56C0C) |
| File | msedgeupdate.txt / msedge.txt | Older branch full payload (SHA256: 443C0A821C214471D74B51093AB3D69BB9BEE54DCDA2551E4F12707) |
| File | st.php.malw | Stage-2 stager, newer branch (SHA256: E9D918FF5F7918CFF1A3A23F3945058A66B56D6DDC7E1CAB95E166D) |
| File | payload_new.php.malw | Full PowerShell payload, newer branch (SHA256: D828949ADE683CF3AC6D4260F946CA33EF8610350EE79EC75DD243B2) |
| File | c9dba5b0552d879be654.txt | Runtime payload extracted from infected host, matches payload_new.php.malw hash |
| File | c9dba5b0552d.vbs | VBS launcher script written to ProgramData for newer branch persistence |
| File | MicrosoftEdgeUpdateCore.exe | Named executable used for persistence in the older detonation branch |
Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.