Introduction

During our investigation, we identified a multi-stage malware infection leveraging Scheduled Task persistence, VBScript launchers, and PowerShell-based execution. The attack operates through two parallel chains: a web-based PowerShell loader that retrieves remote payloads and a secondary PowerShell loader chain that executes the RetroRAT implant.

By abusing legitimate Windows components and executing payloads directly in memory, the attackers minimize disk artifacts and evade traditional detection mechanisms.

Initial Findings

The investigation was initiated after identifying suspicious Scheduled Tasks executing VBScript files from user-accessible directories. The tasks were configured to launch hidden PowerShell commands, indicating potential abuse of native Windows scripting components for persistence.

Further examination revealed multiple suspicious artifacts, including:

• VBScript launchers invoking PowerShell with execution policy bypass
• A PowerShell script (ppamproServiceZuneWAL.ps1) downloading and executing remote content from an external domain
• Additional PowerShell scripts used to execute malicious payloads directly in memory

Outbound connections to a remote web resource hosting Wallet.txt confirmed active command retrieval from an external server, indicating remote command execution capability.

These findings confirmed the presence of a persistent multi-stage compromise leveraging web-delivered payloads and in-memory PowerShell execution techniques.

Infection Chain Overview

The compromise involves two parallel execution chains triggered through persistence established via Windows Scheduled Tasks. Both chains leverage VBScript launchers and PowerShell execution to deploy malicious components while minimizing disk artifacts.

One chain retrieves and executes a remote PowerShell payload that performs cryptocurrency clipboard hijacking. The second chain uses a VBScript launcher (PiceVid.vbs) to execute a PowerShell-based payload (PiceVid.ps1) that deploys the RetroRAT malware for system monitoring, financial activity tracking, and remote command execution.

Chain 1 – Web Backdoor Components

Scheduled Task Persistence

Persistence was established through Windows Scheduled Tasks configured to execute VBScript files from user-writable directories. The tasks invoke PowerShell in hidden mode with execution policy bypass enabled.

This ensures reliable re-execution of the malicious chain while avoiding traditional startup registry mechanisms.

VBS Launcher – ppamproServiceZuneWAL.vbs

This script serves as an execution intermediary, launching PowerShell silently. It does not contain the payload itself but acts as a controlled entry point into the remote loader chain.

Remote Loader – ppamproServiceZuneWAL.ps1

This script functions as a web-based backdoor and performs:

• Single-instance validation via WMI process enumeration
• HTTP retrieval of remote script (Wallet.txt)
• Dynamic execution using [ScriptBlock]::Create().Invoke()

The remote payload is executed entirely in memory. Because the content is hosted externally, it can be updated dynamically, enabling continuous attacker control.

The ppamproServiceZuneWAL.ps1 script acts as a PowerShell-based remote loader and execution controller. Initially, it retrieves its own script name using the $MyInvocation object and runs a function named CURRENT-instance, which checks all running powershell.exe processes through WMI to determine whether another instance of the same script is already active. If a duplicate instance is detected, the script exits to prevent multiple concurrent executions. After ensuring single-instance execution, the script loads the .NET networking library System.Net.Http and uses HttpClient to download remote content from hxxps://anycourse[.]net/wp-content/uploads/2025/04/Wallet[.]txt. The retrieved Wallet.txt file contains PowerShell commands controlled by the attacker. Instead of saving this content to disk, the script dynamically converts the downloaded text into executable PowerShell code using [ScriptBlock]::Create() and executes it directly in memory. This mechanism effectively transforms the script into a web-based backdoor that allows attackers to remotely update and execute commands on the compromised system by simply modifying the contents of Wallet.txt on the server.

Web Payload – Wallet.txt

The downloaded file contains PowerShell instructions delivered from an external server.

This allows the attacker to:

• Issue commands
• Update or redeploy components
• Execute reconnaissance
• Exfiltrate data

This mechanism effectively converts the compromised system into a remotely controlled PowerShell implant.

Wallet.txt contains a PowerShell clipboard-hijacking script designed to steal cryptocurrency transactions. The script continuously monitors the system clipboard for copied text and uses regular expression patterns to detect cryptocurrency wallet addresses such as Bitcoin or other crypto formats. When a matching address is found, the script replaces the copied wallet address with an attacker-controlled address stored in its internal dictionary. As a result, if the victim copies a legitimate wallet address to send cryptocurrency, the clipboard is silently modified so that the funds are redirected to the attacker’s wallet instead. The script continuously monitors the clipboard at regular intervals, allowing the attacker to covertly intercept and redirect cryptocurrency payments on the compromised system.

Attacker-Controlled Cryptocurrency Wallet Addresses

The Wallet.txt payload maintains a dictionary of attacker-controlled cryptocurrency wallet addresses. When a matching wallet format is detected in the clipboard, the malware replaces the victim’s address with the corresponding attacker-controlled wallet.

The replacement addresses cover multiple cryptocurrencies including

Bitcoin (BTC), Litecoin (LTC), Ethereum (ETH), Monero (XMR), XRP, NEO, Bitcoin Cash (BCH), Dogecoin (DOGE), Dash, Stellar (XLM), Binance Coin (BNB), Tezos (XTZ), Tron (TRX), VeChain (VET), DigiByte (DGB), Qtum, Cardano (ADA), Polkadot (DOT), Cosmos (ATOM), Lisk, Kava, Algorand (ALGO), Filecoin (FIL), Nano, NEM, Waves, Zcash (ZEC), Terra, and THORChain (RUNE).

Chain 2 – PowerShell Loader Components

VBS Launcher – PiceVid.vbs

This script triggers execution of PiceVid.ps1, acting as the entry point for the local loader chain and is executed through the scheduled task.

PowerShell Loader – PiceVid.PS1

The script contains the RetroRAT payload and is executed directly in memory.

Instead of writing the payload to a separate executable file, the script reads its contents and executes it dynamically using Invoke-Expression (IEx).

This approach enables the attacker to execute the malware while minimizing detectable artifacts on disk.

The in-memory payload identified during analysis corresponds to RetroRAT, a Remote Access Trojan targeting financial activity associated with U.S. banking institutions and cryptocurrency platforms. The malware monitors user activity, captures keystrokes, and selectively tracks interactions with financial services in order to harvest sensitive information.

Analysis of Payload – RetroRAT

The analyzed payload, referred to as RetroRAT, is a financially motivated Remote Access Trojan (RAT) targeting cryptocurrency and banking-related activity. The malware installs a global keyboard hook and continuously monitors active window titles for keywords associated with financial applications and commonly accessed banking or cryptocurrency platforms. Its modular architecture, combined with a TCP-based command-and-control (C2) communication channel, enables the attacker to execute remote commands, manipulate files, access clipboard data, and dynamically load additional assemblies directly into memory.

Defense Evasion and Anti-Analysis Techniques

The sample implements multiple anti-analysis and defense evasion techniques to avoid detection and restrict execution in analysis environments such as sandboxes, virtual machines, and automated malware analysis systems.

– Sandbox Evasion Checks

The sample contains a hard-coded list of common sandbox and analysis environment identifiers, including known usernames such as “John Doe”, “virus”, “test user”,  “sand box” etc.
During execution, these values are compared against system attributes to detect potential analysis environments. If a match is found, the malware alters its behavior, likely as an evasion mechanism.

– Virtual Machine Detection

Malware also checks if is running under Virtual Machine by querying to Virtual Machine directories, drivers and related services. If it found any traces, it exits itself.

– Use of obfuscation

The payload makes heavy use of basic but effective obfuscation. Method and class names are aggressively renamed, and several identifiers contain Unicode control characters that make them appear broken inside the decompiler. In addition, most meaningful strings are stored encoded and reconstructed at runtime. This prevents straightforward static analysis and forces the analyst to observe values dynamically. Using de4dot, we were able to partially de-obfuscate binary, restoring readable method names.

Mutex Usage

Early during the execution, binary checks if a named mutex is already present into the system. If it is found, malware instantly terminates its execution by using Environment.Exit(0). The technique is commonly used by malware to avoid reinfecting the system.

Multi-Threaded Execution

The malware spawns multiple worker threads to execute different components of its functionality in parallel. This design allows the malware to maintain continuous monitoring and background activity without interrupting other operations such as command-and-control communication or data processing.

– Thread 1 – Keyboard Event Interception Loop

• new Thread(new ThreadStart(GClass25.smethod_1)).Start();

The implant creates a separate execution thread to handle keyboard interception by using SetWindowsHookExA(). Within this routine,  a low-level (WH_KEYBOARD_LL) hook is registered allowing the malware to monitors low-level keyboard input.

Once the hook is installed, thread immediately enters a message loop using Application.Run(). This ensures the hook remains active for the lifetime of the process, allowing the implant to capture keystrokes continuously.

Inside the hook callback, the malware checks whether the intercepted message corresponds to a key press event. The condition if (int_2 >= 0 && intptr_1 == (IntPtr)256) ensures that the hook processes only valid key press events. The value 256 corresponds to the WM_KEYDOWN message in Windows, meaning the code executes only when a key is pressed.

At the end of this thread, malware calls UnhookWindowsHookEx() to remove previously installed keyboard hook. This ensures continuous keystroke monitoring until malware is terminated.

-Thread 2 – Keyword-Based Monitoring of U.S. Banking and Cryptocurrency Services

• new Thread(new ThreadStart(GClass11.smethod_0)).Start();

In addition to the Thread 1 that intercepts keyboard events, the malware launches this additional thread responsible for independently handling runtime checks tied to user’s financial activity.

Firstly, it prepares and initializes directory and names of the log files which are used later for storing the monitoring results. Here, two separate files are initialized, one for cryptocurrency related activity (“crypto_results.txt”) and another for banking related activity (“banks_results.txt”). These files are stored under the user’s %localappdata% directory.

Next, the malware initializes two string arrays named “array” and “array2”. The values of these arrays are dynamically reconstructed at runtime through internal decoding routines. This technique conceals meaningful keywords from static inspection while still allowing the malware to use them during execution.
The first array (array) contains 47 (0x2F) cryptocurrency-related keywords, including platforms such as coinbase, blockchain, bitcoin, and others. The second array (array2) contains 51 (0x33) keywords associated with financial institutions and payment services, including bankofamerica, wellsfargo, chime, and paypal.
A closer inspection of the keywords in array2 reveals the malware author’s strong focus on the U.S. financial ecosystem, covering major national banks, regional institutions, digital banking platforms, and widely used online payment services.

Banking and Cryptocurrency Focused Monitoring Loop

After initializing keyword list and result files, the malware enters a continuous monitoring loop which is designed to track user interactions with the financial services.

Two HashSet objects are created for previously created result files, allowing the malware to avoid duplicate logging and maintain a record of already identified matches.

Inside an infinite loop, the malware repeatedly retrieves the title of the currently active window.

The captured text is normalized using .ToLower() before being compared against predefined keyword lists containing cryptocurrency platforms and banking-related services. Whenever a match is identified and has not been recorded earlier, the corresponding keyword is written to a dedicated results file using File.AppendAllText(). Additionally, the malware begins capturing and recording subsequent keystrokes associated with that session, allowing it to collect potentially sensitive user input related to financial activity.

This logic effectively links foreground user activity with targeted financial keywords, indicating that the malware selectively monitors sessions involving banking services, payment platforms, or cryptocurrency services rather than indiscriminately logging all activity.

C2 Connection and Data Exfiltration

The method smethod_5() implements the malware’s primary command-and-control (C2) communication routine. It continuously attempts to establish a network connection with predefined remote servers and manages the life-cycle of the active communication channel. Once a connection is successfully established, this routine enables further interaction with the remote server, forming the foundation for data exchange and remote control.

Initially, the binary iterates through a list of hardcoded domains (Class15.string_0) and associated ports (Class15.int_0).

For each domain–port combination, a TcpClient object is created.  Once a TCP connection is established, a validation routine (smethod_6) is executed, that act as a handshake check to confirm that the remote server responds with an expected identifier.

Identifier we observed in our sample is string “RETRO-OK-2025”. Connections failing this validation are immediately closed and the next candidate server is tried.
After successful C2 validation malware enables RAT feature that periodically collects captured keystroke data stored in local result files and transmits it to the C2 server.

The malware reads the collected keystroke data from the result file using File.ReadAllText(). The stolen data is combined with victim identification information and packaged into a structured message using the internal packet-building routine (GClass10). The message is then transmitted to the C2 server through the active TCP communication channel (GClass12), where the payload is encrypted before transmission.
This mechanism enables the malware to reliably collect and transmit sensitive user input to the remote C2 infrastructure, allowing the attacker to harvest financial and credential-related information from the compromised system.

RAT Module

As a Remote Access Trojan, the malware supports a range of remote control capabilities. Commands received from the C2 server are processed through a centralized dispatcher implemented as a switch statement, which evaluates command identifiers defined in the GEnum1 enumeration and invokes the corresponding functionality.

Depending on the command value, different modules are invoked to perform operations such as remote desktop monitoring, file system manipulation, command execution, and system control.

This RAT functionality allows attackers to interactively monitor and control the infected system in addition to financial data theft.

RAT Command Capabilities

Targeted Financial Keywords

Conclusion

Operation DualScript is a multi-stage malware campaign that abuses legitimate Windows components such as Scheduled Tasks, VBScript, and PowerShell to maintain persistence while minimizing disk artifacts. The attack operates through two parallel chains: a web-based PowerShell loader that deploys a cryptocurrency clipboard hijacker and a secondary PowerShell loader chain that executes the RetroRAT implant directly in memory.

By combining financial theft through wallet manipulation with remote access capabilities, the attackers achieve both targeted cryptocurrency theft and persistent system monitoring. This campaign highlights the growing abuse of trusted system utilities and in-memory execution techniques to evade traditional detection mechanisms.

Indicators of Compromise

File-Based

Network-Based

Mitre Mapping

Authors:
Niraj Makasare
Prashil Moon
Rayapati Lakshmi Prasanna Sai

The post Operation DualScript – A Multi-Stage PowerShell Malware Campaign Targeting Cryptocurrency and Financial Activity appeared first on Blogs on Information Technology, Network & Cybersecurity | Seqrite.

Table of Contents:

• Introduction
• What is a Homoglyph Attack?
• Practical Homoglyph Confusable
  • Practical Homoglyph Confusable Table
• Why Homoglyph Attacks Are Effective
• Common Homoglyph Use Cases and Attack Vectors
• Real-World Examples and Campaign Patterns
• Technical Deep Dive — Unicode, IDNs, and Punycode
  • Unicode and Scripts
  • IDNs and Punycode
  • Mixed Scripts and Confusable
• Attack Flow — Step-by-Step
• Why Detection Can Fail — Subtle Technical Pitfalls
• MITRE ATT&CK Mapping (High-Level)
• Defensive Measures and Operational Recommendations
  • Policy and Governance
  • Technical Controls
  • Operational Practices
• Best-Practice Checklist
• Emerging Trends to Watch
• Conclusion

Introduction

You glance at a URL, see a familiar brand name, and click — only to hand your credentials to an attacker. That tiny visual mistake (an “o” that’s actually a Greek omicron, a lowercase “l” replaced by a capital “I”) is exactly what homoglyph attacks exploit. Homoglyphs are visually similar characters from different character sets (Latin, Cyrillic, Greek, full-width forms, etc.). When attackers swap characters in domains, filenames, message display names, or code, humans — and often automated defences — are fooled.

Homoglyph attacks are a low-cost, high-impact deception technique. They are used for phishing, brand impersonation, malware distribution, supply-chain confusion, and bypassing simplistic detection rules. This blog explains the technical mechanics (Unicode, IDNs, Punycode), how attackers operationalize homoglyphs, detection and hunting approaches, real-world usage patterns, MITRE mapping, and practical defences — including how layered protections like Quick Heal / Seqrite help.

What is a homoglyph attack?

A homoglyph is a character that looks like another character. For example:

• Latin a (U+0061) vs Cyrillic а (U+0430)
• Latin o (U+006F) vs Greek ο (omicron, U+03BF)
• Latin I (capital i, U+0049) vs lowercase l (ell, U+006C) vs Cyrillic І (U+0406)

A homoglyph attack replaces one or more characters in an identifier (domain, filename, email display name) with visually confusable alternatives to impersonate a trusted resource. When used in Internationalized Domain Names (IDNs), these domains are represented in ASCII using Punycode (the xn-- prefix) but often rendered in browsers using the original Unicode characters — giving an authentic-looking URL to users.

A quick Punycode example (conceptual, anonymized):

Displayed domain:  gοogle-example[.]com    (Greek omicron used instead of Latin ‘o’)

Punycode (ASCII):  xn--gogle-example-abc[.]com

Practical Homoglyph Confusable

Homoglyph attacks exploit visually similar characters from different language scripts such as Latin, Cyrillic, and Greek. These lookalike letters can deceive users, spoof trusted domains, and even bypass some automated filters.

Below is a quick reference showing commonly abused homoglyph pairs seen in phishing and impersonation campaigns.

Practical Homoglyph Confusable Table

Why homoglyph attacks are effective?

1. Human perception: People evaluate URLs visually and are poor at spotting subtle character differences.
2. Display vs. storage mismatch: Systems may store ASCII (Punycode) but display Unicode, introducing confusion.
3. Policy/allowlist gaps: Allowlisting based on visible strings (without normalization) can miss IDN-based lookalikes.
4. Certificate and hosting availability: Attackers can obtain TLS certs for lookalike domains (Let’s Encrypt and similar), raising perceived legitimacy.
5. Automation gaps: Many security pipelines don’t normalize Unicode or run mixed-script detection, so homographs slip through.

Common homoglyph use cases and attack vectors

• Spear-phishing & credential harvesting: Phishing emails contain links to lookalike domains that host credential-collection forms.
• Business Email Compromise (BEC): Invoice/payment scams where the sender’s display name or a domain in an invoice looks correct but contains homoglyphs.
• Malvertising / malware distribution: Executables and updates are hosted on lookalike domains to trick analysts and sandboxes.
• Username/display name spoofing: On Slack/Teams/Email, attackers register accounts where the display name uses homoglyphs to impersonate coworkers.
• Supply-chain & developer confusion: Package names, repo names, or variable identifiers with lookalike characters cause devs to pull malicious code or execute wrong binaries.

Real-world examples and campaign patterns

To stay actionable and responsible, the following are anonymized patterns and publicly reported behaviours (no brand finger-pointing):

• Finance-targeted phishing: Campaigns register lookalike domains of payment portals with mixed Latin/Cyrillic characters, host credential forms, and send follow-ups to improve success.
• SaaS impersonation: Attackers registered IDNs visually identical to a popular SaaS login page to harvest credentials, often pairing the domain with a valid TLS certificate and a convincing HTML login form.
• Executive impersonation in BEC: Display names in email clients (or slight domain modifications) are used to request urgent transfers; perpetrators rely on users not inspecting the actual return-path domain.
• Malware distribution via lookalike downloads sites: Fake download portals (e.g., for installers) hosted on homoglyph domains to push malicious payloads that sandbox detonation misses because domain reputation is new.

Technical deep dive — Unicode, IDNs, and Punycode

Unicode and scripts

Unicode is a comprehensive character set that includes many scripts (Latin, Cyrillic, Greek, Armenian, Hebrew, Arabic, etc.). Many glyphs across different scripts look similar or identical at typical font sizes.

IDNs and Punycode

The Domain Name System (DNS) historically supports only ASCII. To allow non-ASCII names, IDNA (Internationalized Domain Names in Applications) employs Punycode — an ASCII-compatible encoding prefixed by xn--. For example, пример (Cyrillic) becomes xn--e1afmkfd.

Browsers decide whether to display the Unicode form or the Punycode form based on heuristics. If a domain uses characters from a single script and that script matches the user’s locale, browsers often display the Unicode string — which is visually deceptive for someone used to Latin characters.

Mixed scripts and confusable

Attackers often use mixed-script domains, combining Latin letters with a few Cyrillic or Greek characters in positions that are visually sensitive (brand name core, domain label start/end).

Technical mechanics that matter for detection:

• Normalization forms (NFC, NFD, NFKC) change canonical decomposition/composition and affect string comparisons.
• Confusables tables (Unicode consortium) list visually confusable characters; defenders can use these for fuzzy matching.
• BIDI (bidirectional) controls can reverse text rendering (\u202E), used by attackers to obfuscate filenames or display names.

Attack flow — step-by-step

1. Recon & Branding: Attacker gathers brand names, common subdomains, and localized scripts used by the target.
2. Domain prep: Register homoglyph domain(s) via a registrar that accepts IDNs; optionally obtain TLS certs.
3. Hosting & content: Set up phishing page, download portal, or redirect flows; configure email templates to point to the domain.
4. Delivery: Send emails, ads, or social messages linking to the homoglyph domain; exploit typical trust cues (logos, similar wording).
5. Collection & exploitation: Harvest credentials, push malware, monetize via fraud or sale on access markets.
6. Persistence: Use harvested credentials to expand access or register more lookalike domains to rotate campaigns.

Why detection can fail — subtle technical pitfalls

• No Unicode normalization: Tools that compare strings directly without Unicode normalization miss matches.
• Font/rendering variance: Some fonts reveal differences (serifs), others hide them (sans-serif at small sizes).
• Mixed-script heuristics: Not all filters flag mixed scripts; some legitimacy checks only ensure ASCII.
• TLS false sense of security: A valid certificate is not proof of identity; certificate transparency helps but doesn’t block registration patterns.

MITRE ATT&CK mapping (high-level)

• Homoglyph attacks most commonly align with phishing-based initial access, where lookalike domains host credential-harvesting pages.
• Attackers rely on open-source intelligence to craft believable impersonation targets and acquire deceptive domains and TLS certificates during the resource-development phase.
• Masquerading techniques are used to evade defences, ultimately enabling credential theft, fraud, or broader intrusion activity.

Defensive Measures and Operational Recommendations

Policy and governance

• Organizations should maintain a formal domain-defence strategy that includes registering common lookalike domains for high-value brands and services.
• Clear IDN usage policies should prohibit mixed-script domains in official communications.

Technical controls

• Email gateways and web proxies must normalize Unicode and clearly surface Punycode warnings for suspicious links.
• DNS filtering systems should treat newly observed xn-- domains as high risk until reviewed.
• Certificate transparency monitoring should alert security teams when certificates are issued for lookalike domains.

Operational practices

• Brand-monitoring programs should track domain registrations and abuse reports in near real time.
• Phishing simulations should include realistic homoglyph-based scenarios to improve user awareness.
• Incident response playbooks should document takedown workflows, including registrar and hosting provider escalation.

Best-Practice Checklist

• Enforce multi-factor authentication on all sensitive services.
• Normalize and inspect all inbound URLs, displaying Punycode when appropriate.
• Monitor certificate transparency and passive DNS data for newly registered lookalike domains.
• Block or strictly review mixed-script domains.
• Run phishing simulations that include homoglyph techniques.
• Register defensive domain variations for critical brands.
• Require secondary verification for financial or credential-related requests.

Emerging Trends to Watch

• Attackers increasingly automate homoglyph generation and domain registration at scale.
• AI-assisted phishing improves the credibility of lures while homoglyph domains host the deception layer.
• Homoglyph abuse is expanding into software supply chains through deceptive package and repository names.
• Cross-channel impersonation combines homoglyphs with chat platforms and voice cloning to increase trust and success rates.

Conclusion

Homoglyph attacks demonstrate how minor visual manipulation can lead to major security failures. By exploiting Unicode complexity and human perception, attackers bypass both users and poorly normalized defences.

Effective mitigation requires layered controls: Unicode normalization, confusable matching, mixed-script detection, proactive domain monitoring, and strong user verification processes. When combined, these measures significantly raise the cost and complexity for attackers—turning a simple deception technique into a far less effective threat.

Authors

Author: Matin Tadvi
Co-Author: Niraj Makasare

The post Homoglyph Attacks: How Lookalike Characters Are Exploited for Cyber Deception appeared first on Blogs on Information Technology, Network & Cybersecurity | Seqrite.

Table of Contents

• Introduction
• The “Dual-Use Dilemma”: Why Attackers Prefer Legitimate Tools
• Why Antivirus Neutralization Matters
• Historical Evolution of Antivirus Neutralization
• The Ransomware Kill Chain
• Stages of Abusing Legitimate Low-Level Tools
  • Stage 1: Low-Level Tools for Antivirus Neutralization & Privilege Escalation
  • Stage 2: Credential Theft, Kernel Manipulation & Ransomware Deployment Tools
• Live Campaign Examples: From Antivirus Kill to Ransomware
• Threat Actor TTP Mapping (MITRE ATT&CK)
• Emerging Trends & Future Threats
• How Seqrite Protect Against These Activities
• Detection & Incident Response Recommendations for Advanced Threats
• Security Best Practices & Recommendations
• Conclusion

Introduction:

Ransomware isn’t just a piece of malicious code anymore — it’s run like a business. Modern attacks unfold in carefully planned stages, targeting everyone from home users to small businesses and large enterprises. Instead of relying only on custom malware, today’s adversaries act more like penetration testers with bad intentions: they study defences, look for weak spots, and then turn legitimate low-level tools against the very systems meant to be protected.

Take utilities like Process Hacker, IOBit Unlocker, PowerRun, or AuKill. These were originally created to help IT teams troubleshoot systems, manage the registry, or work with drivers. But in the wrong hands, they become weapons, used to silently shut down antivirus protections before ransomware ever shows its face.

Why attackers prefer them:

• Trust Factor: Because they’re digitally signed and commonly used, security systems often treat them as safe.
• Capability: They give attackers SYSTEM- or even kernel-level control, something regular malware often can’t achieve on its own.
• Stealth: Their activity looks like normal admin work, leaving very few traces behind.

This “dual-use dilemma” is exactly what makes them so dangerous — tools designed to fix problems can just as easily be turned into the perfect weapons for dismantling security, all without raising alarms.

Why Antivirus Neutralization Matters

Disabling antivirus isn’t just a minor step in a ransomware campaign—it’s a deliberate tactic to clear the way for payload execution. Security tools are built to block malicious files, record suspicious behavior, and alert defenders in real time. By shutting them down, attackers ensure their operations remain quiet and uninterrupted.

Here’s how disabling security measures directly benefits the attacker:

• Antivirus would block ransomware payloads at the moment of execution.
• EDR would capture and log abnormal file encryption behaviours.
• Forensic artifacts could give SOC teams a chance to respond.
• By disabling these protections, attackers create a silent zone where ransomware can run undetected.

Historical Evolution of Antivirus Neutralization

Ransomware groups haven’t just been standing still—they’ve been steadily refining how they bypass antivirus defences. What started as simple, script-based attacks has grown into highly sophisticated operations, including kernel-level manipulations and ready-made modules that now come standard in ransomware-as-a-service (RaaS) kits. The table below summarizes this progression:

Over the years, attackers have moved from running simple commands to tampering directly with the operating system, and now they rely on automated RaaS kits that bundle antivirus neutralizers by default—making these attacks faster, stealthier, and harder to stop.

The Ransomware Kill Chain

Ransomware attacks typically follow a deliberate sequence of steps, often referred to as the kill chain, which takes an intrusion from initial compromise all the way to widespread encryption and operational disruption. When attackers use legitimate low-level tools, this chain becomes even stealthier and more efficient. Each stage is carefully crafted to bypass defences, gain higher privileges, and ensure the ransomware completes its mission undetected.

• Initial Access – Attackers gain entry through phishing emails, stolen credentials, or misused Remote Access Tools (RATs), establishing their first foothold.
• Privilege Escalation – Tools like PowerRun or YDArk are exploited to obtain SYSTEM- or kernel-level permissions.
• Antivirus Neutralization – Security software is disabled by stopping or unloading antivirus and EDR processes.
• Credential Theft – Utilities such as Mimikatz extract stored passwords and tokens to move laterally across the network.
• Persistence & Cleanup – Tools like Unlock_IT or Atool_ExperModel remove logs and disable startup routines to hide traces of the intrusion.
• Payload Execution – Finally, the ransomware is deployed, encrypting files while blending with normal system activity.

Stages of Abusing Legitimate Low-Level Tools

Adversaries typically follow a 2 stage process when abusing administrative and low-level utilities in ransomware campaigns. Each stage has a clear objective and leverages a distinct set of tools:

Stage 1: Low-Level Tools for Antivirus Neutralization & Privilege Escalation

Attackers often rely on a mix of file unlockers, process killers, privilege escalation utilities, and credential dumpers. By abusing these categories of legitimate tools, they systematically disable antivirus defences, erase traces, and prepare the environment for ransomware execution. The table below consolidates the most commonly abused tools into four major categories.

Stage 2: Credential Theft, Kernel Manipulation & Ransomware Deployment Tools

Once antivirus processes are neutralized, attackers pivot to stealing credentials, manipulating kernel-level defences, and executing ransomware payloads with elevated privileges. These tools are far more dangerous because they operate at the SYSTEM or kernel level, allowing adversaries to move laterally, disable security callbacks, and launch encryption payloads without interruption. The table below highlights the most commonly abused tools in this stage:

Live Campaign Examples: From Antivirus Kill to Ransomware:

Ransomware operators often rely on legitimate low-level system utilities to neutralize Antivirus protections, escalate privileges, and create the perfect environment for payload execution. Below is a consolidated view of widely abused tools and the ransomware campaigns where they have been observed:

Threat Actor TTP Mapping (MITRE ATT&CK)

Every ransomware campaign follows a pattern, and attackers rarely act randomly. They carefully select tools and techniques that align with their objectives at each stage of the attack. By mapping these actions to the MITRE ATT&CK framework, we can better understand how legitimate low-level utilities are repurposed for malicious use.

The table below shows how adversaries move from privilege escalation to disabling defences, stealing credentials, and finally executing their ransomware payload — all while abusing trusted tools that were never designed for crime. This mapping makes it easier for defenders to visualize the attacker’s playbook and identify opportunities to detect or disrupt the intrusion before damage is done.

Emerging Trends & Future Threats

Ransomware is becoming faster, smarter, and harder to detect. Key emerging trends include:

• RaaS Antivirus Killers – Prebuilt scripts in ransomware kits designed to disable antivirus defences automatically.
• Kernel-Level Escalation – Attackers exploit drivers to gain stealthy, high-level control over systems.
• Multi-tool Chains – Utilities like PowerRun, Unlock_IT, and AuKill are combined to bypass security layers reliably.
• AI-Assisted Techniques – AI helps automatically select the most effective neutralization method for each environment.
• Supply Chain Attacks – Trojanized administrative tools and fake software updates create new infection vectors.
• Cloud Endpoint Targeting – Hybrid cloud infrastructures and their security tools are increasingly vulnerable to sophisticated attacks.

These trends indicate that ransomware is evolving toward more automated, precise, and evasive operations, making proactive defence strategies essential.

How Seqrite Protect Against These Activities

Seqrite offer layered defences to counter sophisticated ransomware and Antivirus-neutralization tactics through Seqrte EPP:

• Virus Protection – Identifies and blocks trojanized installers, malicious scripts, and ransomware payloads before they can execute.
• Antivirus Self Protection – Prevents attackers from forcibly terminating or uninstalling Antivirus software.
• Behavioural Detection – Monitors for suspicious actions such as mass process termination, registry tampering.
• Ransomware Protection – Detects abnormal file encryption activity in real time, stopping ransomware before it spreads
• Application Control – Restricts execution of unapproved utilities and administrative tools to prevent misuse. Together, these features provide proactive and reactive protection, keeping endpoints safe even against advanced, multi-stage attacks.

We continuously monitor the threat landscape and proactively hunt for new or modified variants of abused utilities, rapidly updating our detection modules and behavior rules to maintain effective coverage.

Detection & Incident Response Recommendations for Advanced Threats

Protecting against modern ransomware requires proactive monitoring and structured response strategies:

• Process Termination Monitoring – Detect suspicious mass termination of antivirus or EDR processes.
• Registry & File Auditing – Track changes to Antivirus-related registry keys, logs, and startup entries.
• Behavioural Analysis – Identify unusual SYSTEM-level execution and kernel-level modifications.
• Credential Theft Detection – Monitor access patterns to LSASS and other credential stores.
• Application Control – Limit execution to whitelisted administrative tools to prevent misuse.
• Playbooks & Alerts – Automate alerts for attack sequences such as privilege escalation → Antivirus termination → registry/log changes → ransomware execution.
• Endpoint Isolation – Rapidly isolate affected devices to contain the threat and prevent lateral movement.

These steps help organizations detect sophisticated attacks early and respond in a structured, timely manner, reducing the risk of full-scale disruption.

Security Best Practices & Recommendations

Implementing proactive security measures can greatly reduce the risk of ransomware and advanced attacks:

• Enforce MFA for Administrators – Require multi-factor authentication to protect privileged accounts from compromise.
• Enable Application Whitelisting – Block unapproved or unverified binaries, stopping malicious tools before they can execute.
• Monitor Termination Events – Continuously detect and alert on suspicious commands like sc stop, net stop, or taskkill.
• Restrict Low-Level Tool Usage – Limit execution to vetted, business-critical administrative tools only.
• Audit Registry Changes – Track and flag modifications to registry keys associated with Antivirus, EDR, or startup configurations.
• Educate SOC Teams – Train security analysts to spot subtle attempts to bypass or neutralize defences.
• Isolate Administrative Utilities – Provide access to sensitive tools only via secure, monitored jump boxes.

Following these best practices ensures that organizations maintain strong control over critical systems, detect suspicious activity early, and minimize the impact of potential attacks.

Conclusion

Low-level administrative tools, originally designed to make IT operations more efficient, have increasingly been weaponized in ransomware campaigns. Attackers exploit them to disable antivirus and EDR defences, maintain stealthy persistence, and prepare systems for silent, large-scale encryption. What were once trusted utilities have now become some of the most dangerous enablers of cyberattacks.

The key takeaway is clear: dual-use tools represent a serious risk to enterprise security. Combating this threat requires layered defences that combine the strength of Quick Heal / Seqrite protection with strict governance and control over administrative utilities. By reclaiming these tools as trusted allies of defenders rather than weapons for attackers, organizations can deny adversaries their stealth advantage and safeguard critical infrastructure against modern ransomware campaigns.

We continuously monitor the threat landscape, proactively hunt for new or modified tool variants, and feed those discoveries directly into our detection modules — ensuring our coverage evolves as attackers change tactics.

Authors

Author: Matin Tadvi
Co-Author: Sumit Patil

The post Weaponizing Legitimate Low-Level Tools: How Ransomware Evades Antivirus Protections appeared first on Blogs on Information Technology, Network & Cybersecurity | Seqrite.

Contents

• Introduction
• Target
• Phishing Email
• Infection Analysis
  • Stage-1: JavaScript Loader
  • Stage-2: Browser Stealer
• Infrastructure and Attribution
• CVE Assessment
• Conclusion
• Seqrite Coverage
• IOCs
• MITRE ATT&CK

Introduction

Seqrite Labs identified a targeted phishing campaign that exploits a cross-site scripting (XSS) vulnerability in Zimbra Collaboration (ZCS) to compromise a Ukrainian government entity. The phishing email has no malicious attachments, no suspicious links, no macros. The entire attack chain lives inside the HTML body of a single email, there are no malicious attachments.

A social engineered internship inquiry is used to deliver an obfuscated JavaScript payload embedded directly in the email body. When the victim opens the email in a vulnerable Zimbra webmail session, it exploits CVE-2025-66376 which is a stored XSS bug caused by inadequate sanitization of CSS @import directives within the HTML content. The script executes silently in the browser and begins harvesting credentials, session tokens, backup 2FA codes, browser-saved passwords, and the contents of the victim’s mailbox going back 90 days with all the data exfiltrated over both DNS and HTTPS.

Based on technical overlaps with Zimbra exploitation and geopolitical targeting alignment, we assess with moderate confidence that this campaign aligns with tradecraft previously documented with Russian state-sponsored intrusion sets targeting Ukrainian government entities. This has been reported to CERT-UA.

Target

• Country: Ukraine
• Sector: Government

The email recipient is from the Ukrainian State Hydrology Agency that operates in a sector classified as critical national infrastructure responsible for the navigational, maritime and hydrographic support of shipping. It operates under the Ministry of Infrastructure (specifically within the State Service for Maritime and River Transportation of Ukraine). The targeting is consistent with broader cyber operations conducted against Ukrainian public-sector institutions amid ongoing regional conflict dynamics.

Phishing Email

The phishing email was received on 22^nd January 2026 from a student of the National Academy of Internal Affairs (NAVS) to the Ukrainian Hydrology government agency (The student mail ID is likely a compromised one, based on the sender IP in the header). The email message written in Ukrainian, presents as a routine internship inquiry, where the student introduces as a 4th-year student asking if the recipient knows of any internship opportunities or contacts if they could reach out to. Additionally, the sender apologizes in case the email reaches the wrong inbox, which is a classic tactic to build trust.

Key Observations:

• Sent from infrastructure associated with NAVS
• Appears legitimate at first glance
• No malicious attachment, no suspicious external link
• Malicious code embedded directly in HTML body
• Zero detections on VirusTotal, where it was initially identified and uploaded on 26-Feb from Ukraine.

The attacker composed this email manually through the Zimbra web interface on Chrome 132 (stable release on 14-Jan-2026) and not an automated tool behavior.

• 8.15_GA_4717 – SENDER’s Zimbra server version
• 10.1.7_GA_4200002 – ZimbraWebClient front-end UI build number

The email contains hidden malicious JavaScript embedded in <div style=”display:none”> block. It is a large base64-encoded script within the HTML body. The @import tag-name bypass is designed to look like malformed HTML to regex-based inspection while remaining valid to a browser parse.

The exploit in this sample corresponds to CVE-2025-66376, a stored XSS vulnerability in Zimbra Collaboration Suite patched in ZCS 10.0.18 / 10.1.13 (November 2025). The CVE description specifies: “insufficient sanitization of HTML content, specifically involving crafted tag structures and attribute values that include an @import directive and other script injection vectors. The vulnerability is triggered when a user views a crafted e-mail message in the Classic UI.”

The bypass operates on the @import token being stripped from inside tag names and attribute key/value strings. The email also contains secondary decoys using the same principle, broken <script> and <style> tags with @import noise injected into the tag name itself, and an HTML comment inserted mid-tag-name. This tag-name bypass causes AntiSamy to reconstruct <svg/onload=eval(atob(`PAYLOAD`))> from fragmented tokens, and executes the outer Base64 decoded code and the self-executing function runs.

Infection Analysis

Victim receives phishing email in Zimbra webmail. Execution requires the victim to open the email in browser-based Zimbra interface with an active authenticated session. The JavaScript executes within that session context, inheriting its cookies, localStorage, and same-origin SOAP API rights.

Stage-1: JavaScript Loader

The loader is wrapped in a self-executing function that starts with preventing multiple injections by checking if the script with ID “zmb_pl_v3_” is already running or not. The next critical part is decoding the base64 payload using atob() and then performing XOR operation with the key “twichcba5e” to load the final JavaScript payload. It injects the code into top-level document as it contains the session context, access to cookies and escape webmail iframe sandbox.

Stage-2: Browser Stealer

The final payload is a stealer that executes in browser memory. This captures login credentials, SOAP session tokens, mail content and attachments, cookies, etc. It starts with generating a session token for each execution which is a random 12-char alphanumeric string used as a unique victim identifier in every C2 request. The hardcoded C2 domain is zimbrasoft[.]com[.]ua. Any exception caught anywhere in the payload sends POST request to /v/p with the stage name, error message, and stack trace. The C2 operator sees exactly which step failed and why on every victim machine. A try/catch wrapper around every task is seen to isolate failures, so one broken operation doesn’t abort the others.

Then we have the Zimbra SOAP wrapper that sends authenticated SOAP requests to the victim’s own Zimbra server at “/service/soap/”. The X-Zimbra-Csrf-Token header carries the stolen CSRF token, making requests indistinguishable from legitimate webmail activity. The SOAP calls are wrapped to return null on failure instead of throwing error, this allows other parallel operations even if one SOAP call is rejected.

DNS exfiltration encodes values as RFC 4648 Base32 and divides them into 60-character segments and constructs a DNS hostname in this form:

• d-<token>.<key>.<base32_chunk>.i[.]zimbrasoft[.]com[.]ua

Next, it serializes JSON objects as application/octet-stream blobs and POSTs them to /v/d with an X-Filename header, which is used for larger structured objects like the full server config dump. The beacon is a simple POST request to /v/p, used for small structured data alongside or instead of DNS. It can also send the same value through both DNS and HTTPS. DNS gets through even when HTTPS is blocked; HTTPS carries complete data when it isn’t.

Zimbra Classic UI stores the session CSRF token in plaintext here: localStorage.getItem(“csrfToken”). Without it, all SOAP calls would be rejected. This runs first synchronously, before any SOAP operation starts.

All nine parallel operations are launched simultaneously with Promise.all. From the C2’s perspective, this maximizes data yield per victim session if the tab closes after 10 seconds, everything that could fire already has.

SendStartPing: Notifies C2 after the payload execution starts. This lets the attacker correlate start/finish times per victim.

gather_email: Two-method email harvest which first scrapes inline <script> tags for the batchInfoResponse JS variable Zimbra embeds on page load. It falls back to GetIdentitiesRequest SOAP, which returns all configured identities including aliases and exfiltrates via DNS and HTTPS.

gather_environment: Fingerprints the client and calls GetInfoRequest to pull the full server configuration response, then dumps the entire JSON as zimbra_batch_analytics.json. This object contains Zimbra version, account quota, configured features, server hostname, and dozens of account preferences.

1. Classic (?client=advanced)
2. HTML (/h/)
3. Modern (/modern/).

gather_2fa_codes: It uses GetScratchCodesRequest which returns the account’s backup 2FA recovery codes. These are one-time codes meant for emergency access and with them, the attacker can authenticate even if the victim changes their password and revokes all sessions. Each code is exfiltrated individually via DNS.

gather_app_password: This uses CreateAppSpecificPasswordRequest to mint a new persistent credential named ZimbraWeb. App-specific passwords survive password resets. This is the attacker’s long-term access mechanism: once created, it enables direct IMAP or API auth indefinitely, and exfiltrates via DNS.

gather_device_status: GetDeviceStatusRequest (namespace urn:zimbraSync) is used that returns all ActiveSync-connected mobile devices with details like device IDs, types, sync state. It is useful for building a target profile and potentially for follow-on mobile attacks.

gather_oauth_consumers: GetOAuthConsumersRequest is used to list every third-party OAuth app authorized on the account. This reveals other platforms the target uses, and which of them have API-level access to the inbox.

gather_autocomplete_password: It injects two hidden form fields (autocomplete=”username” and autocomplete=”current-password”) off-screen in the DOM and waits 5 seconds for the browser’s password manager to autofill them. Then it reads whatever appeared, exfiltrates it and cleans up all injected elements. This is the only operation that doesn’t need a CSRF token as it targets the browser and not Zimbra.

enable_mail_protocols: The ModifyPrefsRequest sets zimbraPrefImapEnabled: TRUE on the victim’s account. This silently enables IMAP access, which the app password can then use for persistent mailbox surveillance from any IMAP client.

Coming to the most impact section which is sendArchives for 90-day email exfiltration. It loops day 0 through 89, downloading each day’s non-junk emails from Zimbra’s built-in export endpoint “/home/~/?fmt=tgz”. It uploads each day’s .tgz directly through /v/d. Two upload modes are used:

1. Streaming (ReadableStream piped directly, no memory buffer) for modern browsers.
2. Buffered array with a 500 MB cap for older ones.

This uses localStorage keys (zd_comp_YYYY-MM-DD) as checkpoints. If the tab reopens, already exfiltrated days are skipped. The timeout is set to 24 hours per day, meaning it will sit and stream as long as the tab is open.

Finally, the sendFinishPing beacons to confirm that all operations have been completed. The C2 can use start/finish to measure how long a victim session lasted and infer what was captured.

Infrastructure and Attribution

The C2 domain has been created on 2026-01-20 12:10:33+02, just before the phishing email was sent with registrar as ua.drs. Two generated domains have been identified so far:

1. js-l1wt597cimk[.]i[.]zimbrasoft[.]com[.]ua
2. js-26tik3egye4[.]i[.]zimbrasoft[.]com[.]ua

Multiple Russian-linked APTs have previously exploited Zimbra at scale against Eastern European targets: Fancy Bear (APT28), Cozy Bear (APT29) and Winter Vivern (TA473). APT29’s documented Zimbra exploitation is on a command injection vulnerability that steals email credentials via a vulnerable mail server. This is a server-side attack requiring no email interaction, which is a completely different attack class from what we see in the phishing email, which is an HTML email XSS payload requiring the victim to open it in webmail. Whereas TA473 did not use sophisticated tooling but only lighter JavaScript credential stealers with Zimbra XSS vulnerability. This doesn’t have structured SOAP API abuse and no dual-channel exfiltration.

As mentioned under ESET’s Operation RoundPress research in 2024, APT28 expanded from Roundcube to Zimbra, Horde, and MDaemon, targeting governmental entities and defense companies in Eastern Europe. The payload structure we decoded maps closely to SpyPress.ZIMBRA which harvests the victim’s contact list by making a SOAP request to the Zimbra API endpoint and fetches email source for exfiltration. Based on these overlaps and targeting, we attribute Operation GhostMail to APT28 with medium confidence.

Conclusion

Operation GhostMail demonstrates the continued evolution of webmail-focused intrusion, where attackers rely entirely on browser-resident stealers rather than traditional malware binaries. By embedding obfuscated JavaScript directly within an HTML email and exploiting a Zimbra webmail XSS condition, the threat actor achieves full session interception without dropping files, exploiting macros, or triggering endpoint-based detections. The abuse of legitimate SOAP API calls for credential harvesting and mailbox export highlights how platform-native functionality can be weaponized for stealthy data collection.

The targeting of a Ukrainian government entity aligns with ongoing geopolitical cyber activity observed against public-sector institutions in the region. While definitive attribution requires further infrastructure or code-overlap confirmation, the techniques used are consistent with previously documented Russian state-sponsored groups exploiting webmail platforms across Eastern Europe. The importance of strict HTML sanitization in webmail environments, rapid patch management, and monitoring anomalous SOAP activity is indicative of browser-based session compromises.

Seqrite Coverage

Script.Trojan.50486.GC

Recommendations

• Migrate from Zimbra 8.8.15 immediately to a supported release (10.1.x minimum) or an alternative platform.
• Audit all accounts for app-specific passwords named ZimbraWeb or created around the date of any suspicious email. Revoke them immediately.
• Audit account settings for unexpected zimbraPrefImapEnabled: TRUE changes, particularly on accounts that do not have a business need for IMAP access.
• Check Zimbra audit logs for access to /home/~/?fmt=tgz from unusual source IPs or outside normal business hours.
• Deploy SOAP API monitoring at the application layer. Calls to GetScratchCodesRequest and CreateAppSpecificPasswordRequest in particular should be nearly absent in normal usage and easy to baseline.
• Implement DNS filtering for the IOC domains and consider behavioral alerting for the d-[a-z0-9]{12}.i.* subdomain pattern that characterizes the DNS exfiltration channel.
• Review whether IMAP and POP3 access should be enabled by default for user accounts. Disabling unused protocols at the administrative level removes one persistence vector even if credentials are later compromised.
• Brief staff that HTML email bodies can carry executable payloads in webmail environments. The absence of attachments and links is not a reliable safety indicator.

IOCs

Email
c010f64080b0b0997b362a8e6b9c618e

C2
zimbrasoft[.]com[.]ua
js-[a-z0-9]{12}.i.zimbrasoft[.]com[.]ua

MITRE ATT&CK

Authors

Sathwik Ram Prakki
Kartik Jivani

The post Operation GhostMail: Russian APT exploits Zimbra Webmail to Target Ukraine State Agency appeared first on Blogs on Information Technology, Network & Cybersecurity | Seqrite.

• Introduction
• Key Targets
  • Industries Affected
  • Geographical focus
  • Geopolitical Context
• Infection Chain
• Timeline of Activity
• Initial Findings
  • Looking into the Decoy Documents
• Technical Analysis
  • Stage 1 – Malicious Archive Delivery
  • Stage 2 – Malicious Shortcut Execution
  • Stage 3 – HOPPINGANT JavaScript Loader
• Infrastructure & Attribution
• Conclusion
• SEQRITE Protection
• Indicators of Compromise (IOCs)
• MITRE ATT&CK Mapping
• Authors

Introduction

Seqrite Labs APT Team has been monitoring threats across the globe and recently identified a campaign targeting multiple countries. Also looking across the Middle East, taking into account of the current geopolitical tensions. What makes this campaign interesting is the targeting of different regions within a similar timeframe while using the same infection techniques throughout the campaign.

In this blog, we will analyze the infection chain used in this campaign, which starts with a malicious archive and eventually leads to the deployment of a legitimate tool that is abused by the threat actor. We will also look at the infrastructure used in the campaign, where the attackers leverage public anonymous file-sharing websites to host and distribute their payloads.

Finally, we also map the techniques observed in this campaign with the MITRE ATT&CK framework and take a look at the infrastructure used by the attackers.

Key Targets

Industries Affected

• Government agencies
• Defense and military organizations
• Foreign affairs and international cooperation departments
• Policy and diplomatic institutions
• Energy and strategic resource sectors

Geographical Focus

• Algeria
• Mongolia
• Ukraine
• Kuwait

Geopolitical Context

The countries targeted in this campaign may not seem connected at first glance, but each holds a key position in the current geopolitical environment. Ukraine is still at the centre of an active conflict with Russia, with hybrid tactics escalating as we head into 2026. Algeria, one of North Africa’s largest energy exporter, sits at the intersection of competing European, Russian, and Chinese interests. This is especially relevant as Algeria and Morocco approach toward relations and North Africa moves closer to the centre of US regional policy.

Mongolia’s position has grown increasingly complex as it recently deepened ties with China and Russia while simultaneously maintaining Western partnerships, making it a high-value intelligence target for multiple competing state actors. The lure theme used against Mongolia: “Expanding cooperation with China” directly mirrors this tension. Kuwait remains a key Gulf security partner with ongoing defence procurement activities, and the Gulf region broadly continues to face destabilising military activity and strategic competition.

Infection Chain

Timeline of Activity

The following timeline shows the sequence of the campaigns we observed during our research.

Initial Findings

As we have been hunting for malicious spear-phishing threat artefacts, the first interesting threat associated with this campaign was identified on VirusTotal, where we observed a file named وزارة_السكن_والعمران_والمدينة.png.zip. According to the information available, the file was submitted from Algeria on 24th February. The filename translates to “Ministry of Housing, Urban Development, and the City,” which suggests the lure is impersonating an official government entity. Based on this naming convention, the attackers were targeting individuals working in government bodies responsible for housing, urban development, or municipal administration. When we first came across this spear-phishing element, we initially thought it might be a regional activity targeting a specific country.

However, as we continued our research, we identified another sample using the same infrastructure and similar techniques. This sample targeted Mongolia and used the lure Хятад улстай хамтын ажиллагаагаа өргөжүүлж байна.zip. After translating the filename, which is “Expanding cooperation with China,” it suggests that the lure is intended for individuals working in government institutions, diplomatic offices, or organizations involved in international cooperation and foreign affairs.

During further monitoring in March, we found two additional samples that appear to be part of the same campaign. One of the lures was named Algerian Ukrainian proposals for cooperation.zip, which references cooperation between countries and likely targets individuals involved in diplomatic relations, government departments, or organizations engaged in international partnerships. Another sample that we recently observed uses the lure Weapons requirements for the Kuwait Air Force.zip, which suggests that the attackers may be attempting to target defense or military-related entities, particularly those involved in procurement, logistics, or strategic planning.

Looking into the Decoy Documents

The first file from the campaign that we observed in the wild was وزارة_السكن_والعمران_والمدينة.png.zip. The filename is written in Arabic and translates to “Ministry of Housing, Urban Development, and the City.”

The ZIP archive contains two files: دعوة للمشاركة.lnk, which translates to “Invitation for participation.lnk,” and another file named وزارة_السكن_والعمران_والمدينة.png, which means “Ministry of Housing, Urban Development, and the City.png.” Based on the filenames, both documents appear legitimate and are likely intended to trick victims into opening them.

After looking into the decoy image, we found that the logo belongs to an official ministry in Algeria. This suggests that the threat actors likely used the logo to target victims who may be associated with government institutions or related organizations.

The second sample we found was submitted shortly after the first one was shared. The sample was initially packed in a ZIP file named Хятад улстай хамтын ажиллагаагаа өргөжүүлж байна.zip, which translates to “Expanding cooperation with China.” The ZIP file contains two files: Хятад улстай хамтын ажиллагаагаа өргөжүүлж байна.lnk, meaning “Expanding cooperation with China”, and a lure image named Мон-Атом ХХК.jpg.

The image contains the logo of MonAtom LLC, a state-owned company in Mongolia responsible for uranium exploration and nuclear energy development. This suggests that the attackers were attempting to reference or impersonate an organization connected to Mongolia’s nuclear or energy sector. The third payload we found was in the very beginning on the month of March, and it was named Algerian Ukrainian proposals for cooperation.zip.

Further looking into the zip file, we found that it contains two files which are Algerian Ukrainian proposals for cooperation.lnk and MHUV.png. According to the data we found, this file was uploaded from Ukraine. Interestingly, it contains the same logo that we observed in the first sample, which was targeting Algeria and referenced the Ministry of Housing, Urban Development, and the city. By looking at the timeline and the lure theme, we observed that the same threat actor is likely targeting both Ukraine and Algeria, using the same lure and focusing on a similar area of interest in their attacks.

Well, now the most recent sample we found, on 4th March, was WeaponsrequirementsfortheKuwaitAirForce.zip, and the sample was originally uploaded from Italy. But, further looking inside the lure, we found that the targeting was a different geographical location. The ZIP file which we found contains two more files: Weapons requirements for the Kuwait Air Force.lnk and Kuwait Armed Forces.png.

The lure image contains the official emblem of the Kuwaiti Armed Forces, which was likely used to make the file appear legitimate and to gain the trust of the victims targeted by this threat group.

Beyond the image-based decoys mentioned above, the threat actor also deploys another lure document from the remote C2 server, which is part of the later stage of the infection chain.

However, the decoy documents were totally null padded which we believe were likely used to divert the attention of the victims. In this section, we saw the set of decoys in form of images and null-padded documents. In the next section, we will look into the technical analysis of the complete infection chain used by the threat actor.

Technical Analysis

In this section, we will go through the technical details of the infection chain used in this campaign. As mentioned earlier, the campaigns we observed follow almost the same technique, even though the lure documents are different. To explain the behavior clearly, we will focus on the most recent sample.

The infection starts from a ZIP archive that contains a shortcut file along with a lure image. When the victim interacts with the shortcut file, it triggers the next stages of the attack. In the later stages of the infection chain, additional components are downloaded from a public file-sharing website. The attackers eventually make use of Rclone, a legitimate tool, for exfiltration purposes.

Stage 1 – Malicious Archive Delivery

The initial phishing vector we observed was a ZIP file named Weapons requirements for the Kuwait Air Force.zip.

The ZIP file contains two files: Weapons requirements for the Kuwait Air Force.lnk and the official logo of the Kuwait Armed Forces. The LNK file contains a malicious PowerShell command that triggers the next stage of execution, which we will examine in the following section.

Stage 2 – Malicious Shortcut Execution

After looking into the contents of the LNK file, we found that it contains a PowerShell command that connects to the anonymous file-sharing website filebulldogs[.]com to download the further and final payload, which is a JavaScript loader, which we track under the alias of HOPPINGANT.

Looking into the command-line arguments of the malicious LNK file, we found that the command changes the directory to $ENV:Temp, downloads a JavaScript file named f.js from hxxps://filebulldogs[.]com/uploads/AVQB61TVOX/f.js using Invoke-WebRequest, saves it in the Temp directory, and then executes the downloaded script to proceed with the next stage of the attack.

In the next section, we will look into the JavaScript loader, HOPPINGANT which we found this file uniquely used across every campaign we mentioned, making it consistent in terms of the campaign execution. Now, let us look inside the working of the loader.

Stage 3 – HOPPINGANT JavaScript Loader

After looking into the file f.js, which we named the HOPPINGANT loader, we observed that the file contains a Windows Script Host (WSH) JavaScript that creates a Wscript.Shellobject and executes two Base64-encoded PowerShell commands. These commands are executed using the powershell -enc argument, which allows the attacker to hide the actual PowerShell instructions inside encoded data. After decoding the Base64-encoded PowerShell commands executed by the HOPPINGANT loader, we observed that the script performs multiple actions to retrieve additional payloads and prepare the system for data exfiltration.

First, the script changes the working directory to the Temp folder and downloads a file named document.pdf from the remote server hosted on filebulldogs.com. This is the same lure document we mentioned earlier, which is stuffed with null bytes just to distract the victim.

The script also downloads another archive named a.zip from the same remote server and extracts its contents. After extracting the ZIP file, we found an executable file named l.exe, which is later copied to the user profile directory and executed. Upon further analysis, we identified that l.exe is a legitimate software, Rclone, specifically version v1.70.3.

After executing the binary, the script reconstructs a password using a simple XOR-based decoding routine from an array of integer values. Using this decoded password, the script logs into the publicly used remote storage service Mega by creating a new remote profile with the username oliwiagibbons@onionmail[.]org and the decoded password. The email addresses used in all four campaigns are different from other.

Once the remote connection is established, the executable l.exe is used to collect and upload files from the victim’s system. The script specifically targets documents from the Desktop directory, including .doc, .docx, .pdf, and .txt files. In addition, it also attempts to exfiltrate Telegram session data from the Telegram Desktop\\tdata directory. The collected files are then uploaded to the Mega storage account, allowing the attackers to retrieve the stolen data remotely. The threat abuses legitimate software and publicly available services to exfiltrate data from the victim’s system. In the next section, we will look into the infrastructure and attribution related to this campaign.

Infrastructure & Attribution

During our research, we observed that the campaign relies on publicly accessible services to host and deliver the malicious payloads. Unlike traditional APT operations that stand up dedicated C2 infrastructure, this threat actor has entirely built their operation on top of legitimate public platforms, making network-based detection significantly harder.

Initially, we found that the primary network artefact connected to this campaign is the anonymous file-sharing website filebulldogs[.]com, which serves as the sole staging server throughout the entire infection chain. Every campaign we observed, whether targeting Algeria, Mongolia, Ukraine, or Kuwait, uses this same domain to host the HOPPINGANT JavaScript loader (f.js), the payload archive (a.zip), and the decoy documents (document.pdf). However, the threat actor changes the upload path for each campaign by using different directory names such as /uploads/AVQB61TVOX/, /uploads/OKW5RN48ZJ/, and /uploads/F1OQY9GU84/. We believe this helps separate each campaign and reduces the risk of all payloads being removed at the same time. It also allows the attackers to run multiple campaigns within short time periods.

Now, going ahead to the exfiltration side of the operation, we saw that the threat actor abuses MEGA[.]nz, a publicly available cloud storage service, as the remote endpoint for stolen data. The MEGA accounts used across the campaigns are all registered under onionmail.org email addresses, an anonymous email service popular among threat actors for its lack of identity verification. Across the variants we analyzed, we identified four distinct MEGA accounts which are recently registered:

1. coreyroberson@onionmail[.]org – registered on 17-Feb, 2026
2. keatonwalls@onionmail[.]org – registered on 20-Feb, 2026
3. oliwiagibbons@onionmail[.]org
4. theresaunderwood@onionmail[.]org

The credentials used for these accounts are stored inside the HOPPINGANT loader and are hidden using a simple XOR encoding method with the same key value of 56. This key is reused in all the campaign samples we analyzed. In addition, the Rclone configuration parameters remain the same across the campaigns, including 12 threads, 12 transfers, and a bandwidth limit of 100M. The reuse of the same encoding key and identical Rclone settings indicates that all the observed samples are likely part of the same coordinated campaign.

Only one account “Corey Roberson“ contained files around 4 KB in the storage. These have gibberish data written inside documents that have random names.

At this stage, we are not attributing this campaign to any known threat actor. However, the targeting pattern across government, defense, diplomatic, and energy sectors in countries such as Algeria, Mongolia, Ukraine, and Kuwait, combined with the use of geopolitically themed lures, suggests that the activity is broadly consistent with intelligence gathering rather than financial cybercrime. We are tracking these campaigns under Operation CamelClone. The targeting pattern suggests an actor with interests in monitoring the foreign policy positions, defence capabilities, and diplomatic alignments of states navigating major-power rivalries.

Conclusion

Seqrite Labs has identified multiple campaigns that we track as Operation CamelClone. During our investigation, we observed multiple samples targeting government, defense, and diplomatic themes across Algeria, Mongolia, Ukraine, and Kuwait within a short period of time. The attackers rely on ZIP archives with lure documents to initiate the infection chain.

One interesting aspect of this campaign is that the threat actor does not rely on traditional command-and-control infrastructure. Instead, the payloads are hosted on a public file-sharing service, filebulldogs[.]com, while stolen data is uploaded to MEGA storage using the legitimate tool Rclone.

Across the four campaigns analyzed, we observed the same HOPPINGANT loader, the reuse of the same XOR key for password decoding, and similar Rclone configuration parameters. These similarities indicate that the samples are likely part of the same operation.

At this stage, we are not attributing this activity to any known threat group. However, the choice of lures and the sectors referenced in the decoy documents suggest an information-gathering objective. We continue to monitor this activity for overlaps and share updates if additional campaigns related to this operation are identified.

SEQRITE Protection

Lnk.Trojan.50485

Lnk.Trojan.50481.GC

Script.Trojan.50480.GC

Indicators of Compromise (IOCs)

Hash (SHA-256)File

Email-Address

URLs

MITRE ATT&CK Mapping

TacticTechnique IDTechnique Name

Authors

• Priya Patel
• Kartik Jivani
• Sathwik Ram Prakki

The post Operation CamelClone: Multi-Region Espionage Campaign Targets Government and Defense Entities Amidst Regional Tensions appeared first on Blogs on Information Technology, Network & Cybersecurity | Seqrite.

In today’s hyper-connected digital environment, secure communication is not just about encrypting data—it is about preventing attackers from abusing exposed services. Secure communication protocols protect data in transit, but misconfigurations and weak access controls often turn legitimate protocols into attack vectors.

This blog explores secure communication protocols, their implementation, real-world threats such as brute-force attacks, and practical defensive measures aligned with industry best practices.

1. Introduction to Secure Communication Protocols

Secure communication protocols are standardized rules and mechanisms that protect data exchanged across networks. Their primary goals are:

• Confidentiality – preventing unauthorized disclosure
• Integrity – ensuring data is not altered in transit
• Authentication – verifying the identity of communicating parties

Without these protocols, attackers can intercept, manipulate, or impersonate legitimate communications.

2. Core Secure Communication Protocols

TLS/SSL

TLS (formerly SSL) is the backbone of secure internet communication.

• Use cases: HTTPS, APIs, email transport
• Security model: Asymmetric key exchange + symmetric encryption
• Implementation: Requires valid certificates issued by trusted Certificate Authorities (CAs)

IPsec

IPsec secures communication at the network layer.

• Use cases: VPNs, site-to-site tunnels
• Modes: Transport (payload only), Tunnel (entire packet)
• Strength: Protects traffic regardless of application

SSH

SSH enables secure remote administration.

• Use cases: Remote login, command execution, file transfer
• Security: Public key authentication and encrypted sessions

S/MIME

S/MIME secures email communication using PKI.

• Capabilities: Email encryption and digital signatures
• Trust model: Certificate-based identity verification

HTTPS

HTTPS combines HTTP with TLS to secure web traffic.

• Critical for: E-commerce, authentication portals, APIs
• Risk if misconfigured: Weak ciphers or expired certificates.

3. Where Secure Protocols Fail in Practice

Even when secure protocols are deployed, attackers often bypass encryption by targeting authentication weaknesses, especially on services exposed to the internet.

Commonly abused services:

• SMB (445)
• RDP (3389)
• MSSQL (1433)

The most frequent attack technique against these services is the brute-force attack, where automated tools attempt thousands of credential combinations until access is gained.

4. Brute-Force Attacks: Turning Secure Services into Entry Points

What Is a Brute-Force Attack?

A brute-force attack systematically attempts multiple username and password combinations to gain unauthorized access. Once successful, attackers may:

• Deploy malware or ransomware
• Steal sensitive data
• Establish persistent access

These attacks are especially effective against publicly exposed services with weak authentication controls.

5. Attack Flow (Conceptual Diagram)

This flow highlights a critical reality: encryption alone does not stop credential abuse.

6. MITRE ATT&CK Mapping

This mapping shows how a simple brute-force attempt can evolve into a full intrusion lifecycle.

7. Defensive Controls: Securing Services Beyond Encryption

Authentication Hardening

• Use strong, unique, complex passwords
• Avoid default usernames such as Administrator, Admin, SA, root
• Enforce periodic password rotation policies

Account Lockout Policies

• Lock accounts after a defined number of failed attempts
• Apply time-based or administrator-unlock policies to slow automated attacks

MSSQL-Specific Protection

• Disable default SA account
• Change default port 1433
• Restrict public access to database services
• Apply least-privilege access controls

Network Exposure Reduction

• Monitor and restrict access to common attack ports:
  • SMB – 445
  • RDP – 3389
  • MSSQL – 1433
• Allow access only from trusted IP addresses

VPN Over Direct Exposure

Use VPNs with encrypted tunnels instead of direct NAT or port forwarding to reduce attack surface.

Multi-Factor Authentication (MFA)

Enable MFA on all internet-facing services to render brute-force attacks ineffective, even if credentials are compromised.

Defensive Checklist

Use this as a quick security baseline:

• ☐ TLS/SSL certificates valid and using strong ciphers
• ☐ SMB, RDP, MSSQL not publicly exposed
• ☐ Strong password & lockout policies enforced
• ☐ Default accounts disabled or renamed
• ☐ MFA enabled on external services
• ☐ VPN used instead of direct access
• ☐ IDS/IPS logs reviewed regularly
• ☐ Common ports strictly monitored
• ☐ Incident response plan documented

8. Conclusion

Secure communication protocols are foundational to cybersecurity—but they are not sufficient on their own. Real-world security requires combining encryption with strong authentication, controlled exposure, continuous monitoring, and incident readiness.

By aligning secure protocol implementation with brute-force prevention strategies and MITRE ATT&CK–informed defenses, organizations can significantly reduce their attack surface and strengthen their overall security posture.

Authors:

The post Secure Communication Protocols and Their Implementation appeared first on Blogs on Information Technology, Network & Cybersecurity | Seqrite.

But is AI truly a game-changer in cybersecurity? Or is it another overhyped technology riding the wave of digital transformation?

The answer lies somewhere in between.

The Rising Complexity of Modern Threats

Cyber threats today are faster, stealthier, and more automated than ever before. Attackers use AI-driven phishing kits, automated vulnerability scanning, deepfakes, and polymorphic malware to bypass traditional defenses.

Organizations are dealing with:

• Massive volumes of log data
• Distributed cloud environments
• Hybrid workforces
• Expanding attack surfaces
• Increasing compliance obligations

Traditional rule-based security systems struggle in such dynamic environments. Static signatures cannot keep up with constantly evolving threats. This is where AI begins to prove its value.

Where AI Truly Changes the Game

1. Real-Time Threat Detection at Scale

AI-powered systems can process enormous volumes of data across endpoints, networks, servers, and cloud environments. Unlike traditional tools that rely on predefined signatures, AI models identify anomalies and behavioral deviations.

For example, if a legitimate user account suddenly begins downloading large volumes of sensitive data at an unusual hour from an unfamiliar location, AI can flag it—even if no known malware signature exists.

This behavioral analysis significantly reduces detection gaps.

2. Faster Incident Response

Security Operations Centers (SOCs) are overwhelmed with alerts. Many of these alerts are false positives. AI helps by:

• Correlating events across multiple systems
• Prioritizing alerts based on risk context
• Automating initial triage steps

Instead of manually investigating hundreds of alerts, analysts can focus on the most critical threats. AI doesn’t replace analysts—it augments their capabilities.

3. Predictive Threat Intelligence

AI systems can analyze historical attack patterns, threat feeds, and global intelligence data to predict potential vulnerabilities or attack trends.

By recognizing patterns across campaigns, AI can help organizations proactively strengthen defenses before being targeted.

4. Reducing Human Error

Human error remains one of the biggest cybersecurity risks. AI-driven tools reduce reliance on manual configuration and monitoring by:

• Automating policy enforcement
• Detecting misconfigurations
• Identifying risky user behavior

This ensures consistent security enforcement across complex IT environments.

Where AI Falls Short

Despite its strengths, AI is not a magic solution.

1. AI Needs Quality Data

AI models are only as good as the data they are trained on. Poor-quality or biased data can lead to inaccurate detection and blind spots.

2. High False Positives in Early Stages

Without proper tuning and contextual awareness, AI systems may generate excessive alerts. Over-alerting can lead to alert fatigue, the very problem AI aims to solve.

3. Adversarial AI

Attackers are also using AI. Techniques such as adversarial machine learning attempt to manipulate AI systems into misclassifying malicious activity as safe.

The battle is no longer just human vs. human. It is AI vs. AI.

4. AI Cannot Replace Human Judgment

Context matters. Business priorities matter. Risk appetite matters.

AI cannot understand strategic business decisions or nuanced insider threats as well as experienced security professionals can. Human expertise remains irreplaceable.

AI-Augmented Security: The Real Future

The future of cybersecurity is not AI replacing humans. It is AI augmenting human intelligence.

A modern security framework combines:

• AI-driven detection
• Integrated threat intelligence
• Context-aware risk analysis
• Automated response workflows
• Skilled human oversight

This approach ensures faster detection, smarter response, and better resilience.

AI in Enterprise Security: A Strategic Imperative

As enterprises expand into cloud, remote work, IoT, and digital ecosystems, manual security monitoring becomes unsustainable. AI enables:

• Unified visibility across environments
• Proactive risk mitigation
• Reduced mean time to detect (MTTD)
• Reduced mean time to respond (MTTR)

However, organizations must adopt AI thoughtfully, ensuring transparency, continuous tuning, and integration with broader cybersecurity strategy.

So, Game Changer or Overhyped?

AI in cybersecurity is absolutely a game-changer, but only when implemented strategically.

It becomes overhyped when marketed as an autonomous replacement for human expertise.

The real transformation happens when AI is embedded into a holistic, integrated security architecture that delivers intelligence, context, and automation together.

How Seqrite Leverages AI to Deliver Real Security Outcomes

At Seqrite, AI is not treated as a buzzword; it is engineered into the core of our cybersecurity ecosystem.

From AI-powered threat detection and intelligent correlation in Seqrite XDR, to proactive endpoint protection, mobile device management, and data privacy solutions, Seqrite integrates machine intelligence with contextual security intelligence and human-driven expertise.

Our solutions are designed to:

• Detect sophisticated threats beyond signatures
• Correlate signals across endpoints and networks
• Reduce alert fatigue with intelligent prioritization
• Accelerate incident response
• Strengthen enterprise-wide security posture

If your organization is looking to move beyond reactive security and embrace AI-augmented protection that is practical, scalable, and enterprise-ready, Seqrite can help you build a smarter, stronger cybersecurity foundation.

Explore Seqrite’s AI-powered cybersecurity solutions and transform your security operations from reactive defense to proactive resilience.

The post AI in Cybersecurity: A Game Changer or Overhyped? appeared first on Blogs on Information Technology, Network & Cybersecurity | Seqrite.

At Seqrite labs, during our security research, we identified an active Android malware campaign targeting Indian users by impersonating government services, particularly RTO challan notifications and official alerts. These malicious applications are distributed outside the Google Play Store and are primarily shared through WhatsApp and similar messaging platforms.

This campaign represents an evolution of previously observed RTO-themed Android malware, incorporating improved anti-analysis technique, a modular multi-stage architecture, and a more structured backend ecosystem for data collection and remote operations.

Campaign Overview

We observed a three-stage Android malware campaign in the wild, primarily targeting Indian users by masquerading as RTO challan and government-related applications. The malware is distributed outside the Google Play Store and relies on cloud-based backend services for data exfiltration and command-and-control (C2) communication.

Each stage is delivered as a separate APK and is installed sequentially, forming a chained execution flow designed to:

• Maximize infection success
• Maintain long-term persistence
• Perform covert monetization
• Harvest sensitive user data

This modular design allows threat actors to replace or update individual stages without modifying the entire campaign, significantly improving operational flexibility and evasion.

Multi-Stage Infection Chain

The overall execution flow observed is as follows:

Each stage performs a distinct function while remaining tightly integrated with the attacker-controlled backend.

Stage 1 – Dropper and Cryptominer

Primary Functions

• Acts as a dropper for Stage 2 and Stage 3 payloads
• Performs cryptocurrency mining when the device is locked

The first-stage application initiates the infection chain by decrypting and installing subsequent stages (refer to Figure 3). In parallel, it executes a cryptomining module that activates when the device screen is turned off, minimizing user suspicion and visual indicators of malicious activity (refer to Figure 4).

This behavior is consistent with previously documented Android cryptojacking campaigns, where mining operations are deferred until user inactivity to evade detection. Refer to our earlier research – Android Cryptojacker Masquerades as Banking App to Mine Cryptocurrency on Locked Devices

Once the second-stage application is successfully installed, the mining activity of Stage 1 is terminated, and control is transferred to the next component.

Stage 2 – Persistence, Backend Initialization, and Mining

Primary Functions

• Establishes persistence mechanisms
• Initializes backend connectivity
• Initiates its own cryptomining activity

After being deployed by Stage 1, the second-stage application ensures long-term persistence by registering multiple broadcast receivers, hiding its launcher icon, and maintaining continuous background execution.

At this stage, the malware initializes connectivity with its cloud-based backend infrastructure here it is Google’s firebase (refer to Figure 5), which is later used for:

• Victim data storage
• Remote configuration
• Command-and-control communication

Stage 2 also starts an independent cryptomining process, making it both a control layer and a monetization component. This stage effectively acts as a bridge between the initial infection logic and the final surveillance payload.

Stage 3 – Data Theft and Surveillance

Primary Functions

• Social engineering via fake government UI
• Collection of PII and financial information
• Backend-driven C2 communication
• SMS forwarding, notification theft, and call redirection

Upon installation, the third-stage application presents a fraudulent user interface mimicking official government portals, complete with RTO branding and logos. The app prompts users to verify their identity or clear a pending challan.

To proceed, users are instructed to grant multiple high-risk permissions, including SMS access, Call logs, Notification listener, Storage access, etc.

Once these permissions are granted, the malware begins harvesting:

• Personal identity information
• Banking and financial notifications
• OTP messages and transaction alerts
• Device metadata and system information

All collected data is transmitted to the attacker-controlled backend in structured JSON format and stored for further processing. This behavior is consistent with previously documented NextGen mParivahan Malware campaign. Refer to our earlier research – Beware! Fake ‘NextGen mParivahan’ Malware Returns

Backend Infrastructure Access

After analyzing the multi-stage malware, we were able to obtain access to the backend infrastructure used by the threat actors. This provided rare visibility into the operational side of the campaign and allowed us to assess the true impact, scale, and capabilities of the malware ecosystem.

The backend was actively used to store stolen data as well as to control infected devices in real time.

Stolen Data Types

The backend infrastructure contained highly sensitive and security-critical information, including:

• Personally Identifiable Information (PII): Full name, Phone number, Date of birth, Mother’s name, Aadhaar number, PAN number
• Financial and Credential Data: UPI PINs, Credit card details, Net banking usernames and passwords
• Surveillance Data: Intercepted SMS messages, Notification contents, Device status information

This indicates that the malware was not limited to basic phishing but functioned as a full-scale identity theft and financial fraud platform.

Fig. 8 shows a structure in which data is stored by threat actors.

Data collected from user under login page stored in below format –

To identify user and device, device information and other details collected it is stored in this format –

Collected messages stored in below format –

Backend as Command-and-Control (C2)

Beyond acting as a data repository, the backend infrastructure was actively used as a command-and-control (C2) system.

C2 Capabilities Observed

• Remote configuration – Dynamic configuration of SMS forwarding phone numbers
• Tracking and Monitoring – SMS forwarding status, Call forwarding status, Device activity

• Centralized control – Live monitoring of infected devices, Operational status of malware deployment

Effectively, the backend functioned as a central control panel for the operators, enabling them to:

• Manage stolen victim data
• Monitor campaign performance
• Remotely control malware behavior

This confirms the presence of a well-organized and operationally mature threat infrastructure, rather than an amateur or one-off campaign.

Infection Scale and Victim Impact

Based on the records available in the backend infrastructure, approximately 7,400 devices were infected. Not all victims provided every permission or submitted all requested data, but a significant number allowed SMS access and submitted highly sensitive personal and financial information

This demonstrates a large-scale, sustained, and successful compromise of real users, with long-term financial and privacy implications.

Evolution Over Earlier RTO Malware Campaigns

Compared to previously documented RTO and mParivahan malware, this campaign shows significant operational improvements:

These advancements indicate that threat actors are actively refining their tactics, reusing successful components while continuously improving backend operations and persistence mechanisms.

Potential Abuse Scenarios

Based on observed capabilities, the malware enables several high-risk abuse scenarios, including:

• Real-time OTP interception for financial fraud
• Bank account takeover via credential harvesting
• SIM swap facilitation using stolen identity data
• Loan and credit fraud using Aadhaar and PAN details
• WhatsApp and social media account hijacking

MITRE ATT&CK Tactics and Techniques:

Quick Heal Detection of Android Malware:

Quick Heal detects such malicious applications with variants of Android.Dropper.A

It is recommended that all mobile users should install a trusted Anti-Virus like “Quick Heal Mobile Security for Android” to mitigate such threats and stay protected. Our antivirus software restricts users from downloading malicious applications on their mobile devices. Download your Android protection here

Conclusion

This campaign represents a significant escalation in Indian Android malware operations, combining social engineering, modular architecture, cloud-based command infrastructure, and real-time financial surveillance. The three-stage design, coupled with cryptomining and centralized control, indicates a highly organized threat group focused on long-term exploitation rather than opportunistic attacks.

TIPS TO STAY DIGITALLY SAFE:

• Download applications only from trusted sources like Google Play Store.
• Do not click on any links received through messages or any other social media platforms as they may be intentionally or inadvertently pointing to malicious sites.
• Read the pop-up messages from the Android system before accepting or/allowing any new permissions.
• Be extremely cautious about what applications you download on your phone, as malware authors can easily spoof the original applications’ names, icons, and developer details.
• For enhanced phone protection, always use a good antivirus like Quick Heal Mobile Security for Android.

Don’t wait! Secure your smartphones today with Quick Heal Total Security for Mobiles & Smartphones – Buy or Renew Today!

The post Inside a Multi-Stage Android Malware Campaign Leveraging RTO-Themed Social Engineering appeared first on Blogs on Information Technology, Network & Cybersecurity | Seqrite.

For businesses, DPDP is not just a legal obligation. It is about risk reduction, accountability, and customer trust. To comply effectively, organizations must move beyond policy documents and enforceable data protection controls are in place.

What Is the DPDP Act?

The DPDP Act governs the processing of personal data in digital form. Its objective is to ensure that personal data is:

• Collected lawfully
• Used only for a defined purpose
• Adequately protected
• Shared in a controlled manner
• Auditable and accountable

Under DPDP, organizations are responsible for how personal data is collected and protected across endpoints and systems.

What Is Considered Personal Data?

Personal data under DPDP includes any information that can identify an individual, such as:

• Aadhaar, PAN, Voter ID, Passport
• Phone numbers and email IDs
• Financial, payroll, and employee records
• Customer and transaction-related data

In most organizations, this data primarily resides and moves through endpoints i.e, employee laptops, emails, USB drives, shared folders, and cloud applications. Making endpoint-level control critical.

What Organizations Must Take Care Under DPDP

1. Lawful Processing & Purpose Limitation

Organizations must clearly define the purpose for collecting personal data and ensure it is not used beyond that purpose. Unrestricted access or reuse of personal data across departments increases the risk of misuse, over-collection, and unauthorized sharing, which can directly lead to regulatory violations and data breaches.

2. Prevent Unauthorized Sharing of Personal Data

Personal data must not be freely shared through email, removable media, personal cloud storage, or unauthorized applications. Accidental sharing by employees or misuse by insiders remains one of the most common causes of data leaks, making preventive controls essential rather than reactive measures.

3. Implement Reasonable Security Safeguards

DPDP requires organizations to implement “reasonable security safeguards” to protect personal data. This means relying on technical enforcement, not just written policies to prevent exposure, misuse, or loss of sensitive information. In the event of a breach, organizations must be able to demonstrate that protective controls were actively enforced.

4. Detect, Investigate, and Respond to Breaches

Organizations must be capable of detecting personal data incidents quickly and investigating how the breach occurred. Without real-time visibility and detailed logs, incident response becomes slow and ineffective, increasing regulatory, financial, and reputational impact.

5. Enable Data Principal Rights

DPDP grants individuals the right to access, correct, and erase their personal data. Without centralized discovery and tracking, fulfilling these requests across multiple endpoints becomes operationally complex and error-prone, increasing compliance risk.

Why Endpoint Protection (EPP) Alone Is Not Enough

Endpoint Protection Platforms (EPP) are designed to protect systems from malware, ransomware, exploits, and unauthorized access. While essential, EPP focuses on threat prevention, not data usage control.

EPP does not prevent scenarios such as:

• An employee emailing PAN or Aadhaar details to an external recipient
• Copying payroll data to a USB drive
• Uploading customer data to personal cloud storage
• Sharing sensitive files with unauthorized users

DPDP requires organizations to protect the data itself, not just the endpoint. This gap makes Data Loss Prevention (DLP) a critical requirement.

Why DLP Is Essential for DPDP Compliance

Data Loss Prevention focuses on identifying, monitoring, and controlling personal data as it is accessed, shared, or transferred. Without DLP, organizations cannot enforce purpose limitation, prevent accidental leaks, or demonstrate compliance during audits.

In practical terms, DPDP compliance without DLP leaves organizations exposed to insider risk, human error, and audit failures.

How Seqrite EPP with DLP Helps Achieve DPDP Compliance

Seqrite combines Endpoint Protection Platform (EPP) with Data Loss Prevention (DLP) to deliver both security and compliance controls at the endpoint level.

1. Discover and Classify Personal Data

Seqrite DLP detects Indian personal data such as Aadhaar, PAN, Voter ID, Passport, phone numbers, and email IDs using predefined classifiers, regex, and dictionaries. Data-at-Rest scans help identify where personal data exists across endpoints. This enables organizations to gain visibility into personal data locations a foundational requirement for DPDP compliance.

2. Enforce Purpose-Based Data Usage

Seqrite allows organizations to define DLP policies aligned with business functions such as HR, Finance, and Legal. Controls can be applied based on endpoint, applications, file types, and data channels to ensure personal data is used only for its intended purpose. This reduces over-collection and prevents unauthorized reuse of sensitive data.

3. Prevent Data Leakage at the Endpoint

Seqrite DLP enforces controls across endpoints, email, removable media, and network shares. Unauthorized data transfers can be blocked or monitored in real time, significantly reducing the risk of accidental or intentional data leakage. This ensures personal data does not leave the organization through uncontrolled channels.

4. Strengthen Breach Detection and Audit Readiness

Seqrite provides real-time alerts, detailed incident logs, and exportable reports for investigations and audits. Organizations can trace who accessed, copied, or attempted to share personal data, enabling faster response and regulatory readiness. This supports DPDP breach notification and accountability requirements.

5. Support Data Principal Rights

Using Data-at-Rest scans and identity-based searches, Seqrite helps organizations locate personal data linked to individuals. Deleted or restricted data can be monitored to prevent reappearance, supporting access, erasure, and grievance handling obligations.

Conclusion

DPDP compliance cannot be achieved through policies alone, it requires continuous visibility, control, and accountability over personal data.

While Endpoint Protection Platforms (EPP) secure systems against cyber threats, they do not control how personal data is accessed, used, or shared. Data Loss Prevention (DLP) fills this critical gap by ensuring personal data is handled lawfully and securely across endpoints and communication channels.

Together, Seqrite EPP with DLP provides a strong, practical foundation for DPDP compliance, helping organizations reduce regulatory risk, prevent data leakage, and build lasting trust with customers and regulators.

The post India’s DPDP Act: Organizational Responsibilities and the Role of Seqrite appeared first on Blogs on Information Technology, Network & Cybersecurity | Seqrite.

• Privacy as a Moat: In 2026, privacy is no longer a legal “tax”; it’s a competitive advantage that accelerates sales and builds brand equity.
• The End of Data Hoarding: Storing “just in case” data is now a high-interest “Privacy Debt” that creates liability without value.
• The AI Mandate: In the age of Generative AI, data provenance (knowing where your data came from) is the new gold standard for enterprise accountability.

Every January 28th, Data Privacy Day serves as a global checkpoint. But in 2026, the conversation has moved far beyond “changing passwords.” We have entered the Operational Era of Privacy. With India’s DPDPA in full force and the EU AI Act setting new global benchmarks, the enterprise world is facing a fundamental truth: You cannot build a high-performance business on low-trust data.

The 2026 Reality: Data is a Liability, Not Just an Asset

For decades, the “Big Data” mantra was: Collect everything, figure it out later. In 2026, that strategy is a ticking time bomb. Every kilobyte of unconsented or “dark” data you store is a liability.

• The Trust Tax: Recent studies show that 81% of B2B buyers now list “Data Sovereignty” as a top-three requirement. If you can’t prove where your data is stored and how it’s protected, you aren’t just failing a security audit – you are losing the deal.
• The “Privacy Debt” Crisis: Enterprises are realizing that manual data mapping is impossible. When data is scattered across thousands of SaaS apps, “Privacy Debt” accumulates, making it impossible to respond to a single deletion request without pulling engineers off their core roadmap.

From “Legal Checkbox” to “Core Product Experience”

The most successful organizations today are those that have moved privacy out of the legal department and into the product DNA.

1. Privacy as a UX Metric: Gone are the days of 50-page Terms of Service. In 2026, transparency is a feature. If a user can’t manage their consent or see their data footprint in a few clicks, the user experience has failed. We are moving toward “Privacy-by-Design,” where the default state is protection.
2. The AI Paradox: AI is hungry for data, but regulations are hungry for accountability. Organizations are now using Privacy-Enhancing Technologies (PETs) and synthetic data to train models. The goal? Gaining the insights of AI without ever risking the exposure of a single customer’s PII (Personally Identifiable Information).
3. Data Minimization is the New Optimization: The leanest companies are the safest ones. By practicing strict data minimization, deleting what you don’t need the moment you don’t need it – you aren’t just complying with laws like the DPDPA; you are reducing your attack surface and improving system performance.

Beyond the Banner: A Call to Action

Data Privacy Day is a reminder that behind every data point is a human being.

As we look at the year ahead, the challenge for every leader is to stop asking, “How do we stay compliant?” and start asking, “How do we become the most trusted name in our industry?“ The companies that win in 2026 will be the ones that view privacy not as a brake on innovation, but as the engine that makes innovation possible.

Key Takeaways for 2026

• Audit Your “Dark Data”: Identify what you have, why you have it, and delete the rest.
• Automate the Workflow: Move away from manual spreadsheets to automated data discovery.
• Build for Transparency: Make consent and data rights a seamless part of your user interface.
• Honor the Individual: Data belongs to the person, not the platform. Treat digital sovereignty as a core value rather than a compliance burden.

Happy Data Privacy Day. Let’s build a future where trust is the default.

The post Data Privacy Day 2026: Why the “Privacy-First” Enterprise is Winning the Trust Race appeared first on Blogs on Information Technology, Network & Cybersecurity | Seqrite.