Environment Preparation (Before Execution)

Before analyzing or executing the sample, a controlled virtual environment was prepared to prevent accidental data exposure or system compromise.

• Virtual Machine: Flare-VM

• No personal files, credentials, or browser logins

• Network: Host-only (no direct internet access)

• VM hardening:

  • make sure there are no shared folders between your VM and Host OS.

  • disable drag and drop

  • disable clipboard sharing

This setup ensures safe analysis and prevents unintended data leakage or malware spread.

Static analysis

1 File Type Identification:

To identify the file type without executing it, multiple tools were used:

• HxD / PE Header Viewer – to inspect raw headers

• Command-line tools – similar to the file command in Linux

• PEStudio – automated PE inspection

The file begins with the MZ (4D 5A) signature, confirming a valid DOS header required by Windows PE files. The embedded DOS stub message, “This program must be run under Win32”, further indicates that the executable is intended to run on Windows systems. Together, these artifacts confirm that the sample is a legitimate Windows Portable Executable (PE) file.

PEStudio classifies the sample as a 32-bit Windows GUI executable. The file exhibits high entropy (~7.9), indicating possible packing or compression. The absence of a trusted digital signature further supports the need for deeper analysis.

2 File Hash and Lookup:

File hashes were calculated using:

• Command line (certutil)

• HashCalc / HashMyFiles

"When you right-click a malicious file and use HashMyFiles, it generates a unique cryptographic fingerprint. Since this hash is based solely on the file's content, you can instantly confirm a file is malware if the hashes match—even if the file has been renamed to hide its identity."

Hashes were then queried on:

• VirusTotal

• Hybrid Analysis

These platforms aggregate results from multiple AV engines and provide: Detection status, Network indicators,Dropped files, Behavioral reports, MITRE ATT&CK mappings

3 Strings:

String extraction was performed using:

• PEStudio

• Command-line strings utility

During string analysis, no meaningful ASCII strings were identified, which suggests the file content is packed or obfuscated. However, Unicode string analysis revealed several indicators showing that the file is using legitimate Windows

External research:

I noticed reference related to Inno Setup, such as the official documentation URL, the InnoSetupLdrWindow loader, and installer parameters like /GROUP and /COMPONENTS. These findings confirm that the sample is using a legitimate Inno Setup installer framework.

Since Inno Setup is commonly used to package software on Windows, attackers often abuse it to hide malicious payloads inside an installer. In this case, the payload is likely packed or downloaded at runtime, which explains the absence of meaningful ASCII strings during static analysis. Overall, this suggests the malware is masquerading as a normal installer while acting as a loader to deliver its payload.

Command-line usage: using Strings

• -a → ASCII strings

• -u → Unicode strings

• -n → minimum string length

4 Unpacking Considerations:

Exeinfo suggested InnoExtractor, indicating the file matches an Inno Setup pattern.
However, successful extraction depends on whether:

• The payload is stored as standard installer data, or

• It is unpacked dynamically during execution

This means static extraction may not always recover the real payload.

Dynamic Analysis:

Tools Used

The following tools were used to observe runtime behavior and system impact during execution:

• Process Monitor – to track process creation, file system activity, and registry modifications

• TCPView – to observe active and listening network connections

• Autoruns – to identify persistence mechanisms

• Regshot – to compare registry and filesystem changes before and after execution

• Wireshark – to capture and analyze network traffic

Before executing the sample, Regshot was opened and a baseline snapshot (1st shot) of the system was taken.
All monitoring tools (Process Monitor, TCPView, Autoruns, and Wireshark) were then launched to ensure full visibility of runtime behavior.

Once monitoring was in place, the malware was executed and system activity was observed in real time.

Run the malware

as soon as it executes. it created a file named Ripper.exe on Desktop

Process Tree

the following sequence of actions was observed on Process Tree.

1. Initial PowerShell Execution
   The installer first launched PowerShell with ExecutionPolicy Bypass and a hidden window.
   This PowerShell instance executed a script named defender_exclusions.ps1, indicating an attempt to modify or weaken Windows Defender protections before proceeding further.

2. Payload Deployment and Execution
   Immediately after the PowerShell script completed, another PowerShell command was executed to launch Ripples.exe using the RunAs option.
   At this stage, Ripples.exe was created on the Desktop and executed with elevated privileges, confirming it as the primary payload.

3. Persistence via Scheduled Task
   Following payload execution, the malware created a Scheduled Task using schtasks.exe.
   The task was named: Microsoft\Windows\NEW and configured to execute: C:\Users\Public\MyApp\non.exe

On Autoruns we can view a new task is created “under scheduled tasks”.

Right-clicking the entry and selecting “Jump to Entry” reveals the scheduled task details, such as execution history and run conditions.

4. Task Behavior
   The scheduled task was configured to run every minute with the highest privileges, effectively acting as a watchdog mechanism.
   This ensures that the malware is repeatedly triggered and remains persistent across system restarts or process termination.

Regshot

Regshot was used to compare the system state against the baseline snapshot taken before execution. The comparison highlighted registry changes introduced after the malware was run.

Network Activity

Network analysis using Wireshark and TCPView showed:

• No outbound TCP or UDP connections initiated by the malware

• Only standard Windows background traffic, including:

  • DHCP

  • ARP

  • SSDP

No evidence of command-and-control (C2) communication was observed.

This behavior suggests the malware is designed to:

• Wait for valid internet connectivity

• Suppress network activity in isolated or analysis environments

• Rely on a watchdog component to activate network communication at a later time

New Files Hash lookup

Ripper.exe Hash:

When the hash of Ripples.exe was queried on VirusTotal, it was not flagged as malicious by any antivirus vendor. The platform indicated that the file had been analyzed approximately 26 days earlier, suggesting low prevalence and limited detection coverage at that time.

Upon reanalyzing the same hash on 01-02-2026, one vendor flagged the file as malicious. Such delays in detection are common with new or evolving malware, as security vendors require time to observe real-world behavior, develop detection signatures, and update their engines.

This case highlights an important limitation of reputation-based analysis: the absence of detections—especially when a file was last analyzed weeks earlier—does not imply that a file is benign. Relying solely on VirusTotal results can lead to false conclusions, particularly for low-prevalence or emerging threats.

Effective malware classification must therefore incorporate behavioral analysis, including execution flow, persistence mechanisms, and system modifications, rather than depending exclusively on static reputation checks.

non.exe:The hash lookup for non.exe showed it was flagged as malicious, confirming its role as a secondary payload or persistence component within the malware chain.

Detection and Hunting Use Case

These identified malware files (Ripples.exe and non.exe) can now be leveraged to:

• Create YARA rules based on:

  • File hashes

  • Embedded strings

  • Behavioral indicators

• Perform threat hunting across systems to identify:

  • Files with similar characteristics

  • Matching hashes

  • Related network indicators (domains, IPs)

• Detect potential infections exhibiting similar execution or persistence behavior

Key Takeaway

This sample demonstrates a multi-stage, installer-based malware design in which:

• A legitimate installer framework is abused to mask malicious activity

• The installer functions as a loader, not the primary payload

• Persistence and defense evasion are established during installation

• Payload execution is conditional and environment-aware

• Network communication is delayed to evade detection

Even in the absence of immediate C2 traffic, the confirmed execution chain, persistence mechanism, PowerShell abuse, and security evasion techniques clearly indicate malicious intent.