Settra Ransomware: Inside a New Enterprise-Grade Extortion Threat

Background & Intrusion Kill Chain

Settra intrusions follow a calculated, hands-on-keyboard methodology characteristic of modern Ransomware-as-a-Service (RaaS) operations. Threat actors gain initial access primarily through valid credentials obtained from infostealer marketplaces or compromised VPN gateways.

Once inside the perimeter, the operators conduct low-and-slow reconnaissance using dual-use network scanners (such as NetExec), extract credentials via LSASS memory dumping (Mimikatz / ProcDump), and establish durable command-and-control using remote management software such as Mesh Agent. To clear the runway for encryption, attackers deploy edr_blind utilities and weaponize known vulnerable drivers—specifically signed drivers from Safetica’s STProcessMonitor family (STProcessMonitor_v114.sys)—to terminate security software from Ring-0 via Bring Your Own Vulnerable Driver (BYOVD) primitives.

Only after data exfiltration is complete and local defenses are impaired do the operators deliver the Windows encryptor (win64.exe).

Victim Impact Artifacts

When Settra executes on an unprotected endpoint, it transforms the target environment into an unmistakable extortion showcase.

Wallpaper Hijack

Settra drops a high-resolution branded warning graphic to C:\Users\Public\NOTICE.png. The implant immediately forces this graphic as the active desktop background by calling SystemParametersInfoA(SPI_SETDESKWALLPAPER) and configuring registry keys under HKCU\Control Panel\Desktop (Wallpaper, WallpaperStyle, TileWallpaper). The notice instructs victims that their files have been encrypted, directs them to RESTORE_FILES.txt, and warns against altering file extensions or attempting third-party decryption.

Technical Analysis

All reverse engineering was performed statically in an isolated research environment without executing live malware samples.

The recovered payload is a 64-bit Windows PE compiled with MinGW-w64 / GCC 16.1 (MSYS2), containing an asInvoker manifest and unpacking to ~3.01 MB in memory.

Figure 3: Two-Stage Encryptor Architecture (Outer Armor Loader vs. Inner Ransomware Engine)

Stage A — The Outer Defensive Packer

The dropped file (win64.exe) presents an impenetrable static profile: a minimal .text section, almost no conventional imports in its Import Address Table (IAT), and an encrypted 1.4 MB blob embedded in .rdata.

A1. PEB Dynamic API Hashing

The packer avoids static API imports by dynamically walking the Process Environment Block (PEB → Ldr → InMemoryOrderModuleList) to resolve kernel32.dll and ntdll.dll. Exported functions are resolved using a custom hashing algorithm based on djb2:

hash = hash × 33 + char (seed = 0x1505)

Through this mechanism, the loader dynamically obtains pointers to memory allocation, process creation, and thread context manipulation routines: VirtualAlloc, VirtualAllocEx, WriteProcessMemory, GetThreadContext, SetThreadContext, NtUnmapViewOfSection, CreateProcessA, and ExitProcess.

A2. Anti-Debug & Fail-Closed Gateways

Figure 4: Outer Packer Anti-Analysis & Execution Decision Gates Flowchart

Settra implements strict fail-closed checks designed to thwart dynamic analysis in automated sandboxes:

1. BeingDebugged Check: The loader inspects PEB.BeingDebugged. If a debugger is attached, it calls ExitProcess(0).
2. Mandatory CLI Password: The process inspects its command line. If the –pass argument is missing or followed by an empty string, it immediately terminates with ExitProcess(0).
3. Stub Allocation Gate: If memory allocation for the decryption stub fails, the process exits with ExitProcess(0xC).
4. Cryptographic Validation Gate: If password verification, AES-CTR decryption, or decompression fails, the process exits with ExitProcess(0xD).
5. Parent Execution Exit: Upon successfully launching and hollowing the child process, the parent process exits with ExitProcess(0).

Because exit code 0 is returned on debugger detection, missing parameters, and clean termination, automated sandboxes that simply execute binaries without parameters report benign status.

A3. Decryption & LP77 Decompression Pipeline

Figure 5: In-Memory Decrypt and Inflate Pipeline (KDF → AES-256-CTR → Custom LP77 Decompressor)

The operator-supplied password passed via –pass serves solely as a packer unlock secret; it does not decrypt victim files.

1. The packer allocates an RWX memory region and deobfuscates a compact shellcode stub using a build-specific single-byte XOR key.
2. The stub executes a compute-heavy Key Derivation Function (KDF): it hashes the password with salt bytes extracted from the encrypted header, then iterates SHA-256 for approximately 200,000 rounds to derive an AES-256 encryption key.
3. The encrypted payload located in .rdata is decrypted using AES-256-CTR, initialized with the 16-byte IV located in the blob header.
4. The decrypted buffer begins with a mandatory magic signature: `LP77`. The stub validates this header and unpacks a custom LZ77-compressed stream to reconstruct the full, uncompressed inner ransomware executable in memory.

Figure 6: Static Decompression Verification: Decrypted Outer-Blob Revealing LP77 Header & Valid MZ/PE Signature

Cynet Research Labs successfully reconstructed Settra’s decompression routine, verifying the LP77 header and unpacking the complete inner executable.

A4. Process Hollowing Execution

Once the inner PE is fully reconstructed in memory:

1. The loader calls GetModuleFileNameA to retrieve its own image path on disk.
2. It launches a child instance of itself in a suspended state using CreateProcessA(…, CREATE_SUSPENDED).
3. If the –cmd parameter was supplied on the parent command line, the loader strips the –pass <secret> argument from the child’s command-line parameters in memory, preventing the unlock password from appearing in command-line logging.
4. It unmaps the original child binary via NtUnmapViewOfSection, allocates memory at the preferred base using VirtualAllocEx, and writes the decrypted PE headers and sections into the child using WriteProcessMemory.
5. It adjusts the child thread’s entry point via SetThreadContext and triggers execution with ResumeThread.
6. The parent process terminates with ExitProcess(0), leaving the hollowed child running under the original binary name.

Stage B — The Inner Ransomware Engine

The unpacked inner ransomware is a feature-rich, standalone encryptor. Rather than storing strings in plaintext, all operational parameters, service names, commands, and note templates in .data are obfuscated with individual single-byte XOR keys.

Figure 7: Inner Ransomware Host Preparation: Anti-Forensics, Recovery Destruction & Hyper-V VM Shutdown Architecture

B1. Hyper-V Virtual Machine Interception & Shutdown

In virtualized and server environments, virtual machines maintain continuous, exclusive write locks on their virtual hard disks (.vhdx, .vhd, .avhdx). A ransomware process attempting to encrypt these files while the guest OS is running will encounter OS sharing violations (ERROR_SHARING_VIOLATION), leaving the critical virtual hard disks untouched.

To eliminate this barrier, Settra includes a dedicated Hyper-V discovery and shutdown module:

• It connects to the Windows Management Instrumentation (WMI) virtualization namespace: ROOT\virtualization\v2.
• It queries for all registered virtual machines using WQL:

SELECT * FROM Msvm_ComputerSystem WHERE Caption='Virtual Machine'

• For each discovered virtual machine instance, it invokes the WMI method RequestStateChange with a state parameter of 3 (Disabled / Power Off).
• This command forces the hypervisor to gracefully power down all running guest virtual machines, closing active disk handles and releasing exclusive locks so that Settra can encrypt the multi-gigabyte virtual hard drive storage.

B2. Multi-Pronged Recovery Disablement

Settra systematically disables all built-in Windows disaster recovery and rollback features:

• Windows Recovery Environment (WinRE): Executes reagentc /disable >nul 2>&1 to prevent recovery boot menus from operating.
• Boot Configuration Data (BCD): Executes bcdedit /set {default} recoveryenabled No >nul 2>&1 and bcdedit /set {default} bootstatuspolicy ignoreallfailures >nul 2>&1, ensuring that boot failures will not trigger recovery environments.
• Windows Server Backup: Executes wbadmin delete catalog -quiet >nul 2>&1 to erase the Windows Server Backup metadata catalog.
• System Restore: Invokes PowerShell to deactivate system protection:

powershell -Command "Disable-ComputerRestore -Drive 'C:\'" >nul 2>&1

• Stealth VSS Shadow Storage Constriction: Rather than issuing the conspicuous and heavily monitored vssadmin delete shadows command, Settra shrinks the maximum shadow storage allocation:

vssadmin resize shadowstorage /for=C: /on=C: /maxsize=401MB >nul 2>&1

By restricting shadow storage to 401 MB, Windows Volume Shadow Copy Service is forced to automatically purge all historical shadow copies to comply with the storage boundary, silently destroying restore points without generating standard shadow deletion alerts.

B3. 12-Step Anti-Forensics & Log Obliteration

To severely impede incident response and digital forensics, Settra executes a comprehensive 12-target log wiping sequence using wevtutil cl:

1. Application
2. Security
3. System
4. Setup
5. ForwardedEvents
6. Microsoft-Windows-PowerShell/Operational
7. Microsoft-Windows-TaskScheduler/Operational
8. Microsoft-Windows-Defender/Operational
9. Microsoft-Windows-TerminalServices-LocalSessionManager/Operational
10. Microsoft-Windows-TerminalServices-RDPClient/Operational
11. Microsoft-Windows-Sysmon/Operational
12. Microsoft-Windows-WinRM/Operational

Beyond event logs, Settra obliterates secondary forensic artifacts:

• Windows Prefetch: Recursively deletes files under C:\Windows\Prefetch\* to eliminate evidence of executed utilities and malware execution timing.
• PowerShell History: Deletes PSReadLine\ConsoleHost_history.txt to remove operator command-line records.
• Browser & RDP Caches: Purges browser history, terminal server caches, and setup logs (C:\Windows\System32\LogFiles\WinRM).
• DNS Resolver Cache: Executes ipconfig /flushdns to clear network resolution records.
• NTFS USN Change Journal: Invokes fsutil usn deletejournal /d C: to delete the NTFS Update Sequence Number change journal, preventing forensic investigators from reconstructing the timeline of file modifications.

B4. Restart Manager Process Unlocking

To encrypt files held open by database engines, office suites, and mail servers, Settra utilizes the native Windows Restart Manager API:

1. It initializes an active session via RmStartSession.
2. It registers target locked files using RmRegisterResources.
3. It queries the processes holding open locks via RmGetList.
4. It issues RmShutdown(RmForceShutdown), terminating locking applications so their handles are released for immediate encryption.

B5. Hybrid Cryptography Engine

Settra leverages the native Windows Cryptography API: Next Generation (CNG / BCrypt):

• BCryptGenRandom generates an ephemeral 256-bit symmetric encryption key for each file.
• BCryptGenerateSymmetricKey and BCryptEncrypt encrypt the file contents.
• BCryptImportKeyPair loads an embedded, obfuscated 4096-bit RSA-1 public key (BCRYPT_RSAPUBLIC_BLOB).
• BCryptEncrypt encrypts the ephemeral symmetric key using the RSA public key.
• The wrapped key, initialization vector, and metadata are appended directly to the encrypted file.

The encryptor binary contains only BCryptEncrypt—it does not import BCryptDecrypt and contains no private key material. File decryption is mathematically impossible without the threat actors’ offline private key.

Stage C — Data Theft vs. Encryption Separation

Figure 8: Operational Separation: Pre-Encryption Network Exfiltration vs. Strictly Local Destructive Encryption

In post-incident debriefs, organizations frequently ask whether the encryptor uploaded their files to the darknet. Static reverse engineering confirms that Settra’s encryptor contains no network exfiltration capabilities:

• The binary does not link against winhttp.dll, wininet.dll, ws2_32.dll, or urlmon.dll.
• It contains no network sockets, HTTP client code, curl wrappers, cloud storage APIs, or file-transfer protocols.
• Network-related imports are strictly limited to MPR.dll (WNetAddConnection2A, WNetGetConnectionA, WNetCancelConnection2A) to mount SMB shares for local encryption.

The ransom note’s claims of massive corporate data theft describe pre-encryption operator activity conducted during the intrusion phase (via VPN tunnels, RMM tooling, and tools like rclone). The encryptor itself is strictly a local destructive weapon.

Cynet: Proactive Prevention & Detection Showcase

Modern threat actors engineer their payloads specifically to bypass traditional signature scanners. Settra arrives unsigned, wrapped in a custom AES-CTR crypter, and will not execute without an operator password.

Cynet’s multi-layered defense architecture stops this ransomware variant instantly—preventing encryption entirely in Block Mode, and generating deep, multi-stage forensic telemetry in Detection Mode.

1. Proactive Block Mode: Zero-Day Neutralization

In Block Mode, Cynet eliminates the threat before a single victim file is compromised. Rather than waiting for known file hashes, Cynet employs kernel-mode driver monitoring combined with intelligent Decoy File (Honeypot) Deception.

Figure 10: Cynet Proactive Block Mode: (Top) Critical Automated Remediation Banner; (Bottom) Intercepted File Operation Attempt with 1-Second Process Kill

• Instantaneous Remediation: As seen in the Cynet console, Settra executed with SYSTEM privileges (nt authority – system). Within one second of detonation (First Seen: 14:48:27, Last Seen: 14:48:28), Cynet automatically flagged the operation as CRITICAL and triggered an automated Kill Process remediation action.

Figure 11: Cynet Kernel Driver Interception: Kill Process Executed on Unauthorized Attempt to Touch Decoy Honeypot Directory (! Protection)

• Kernel-Level Decoy Trapping: Cynet strategically deploys canary files across monitored volumes When Settra initiated file overwrite and note-creation operations (RESTORE_FILES.txt / *.locked_wip) inside the canary directory, Cynet’s driver intercepted the file operation.
• Action Executed: While the policy requested Block Access, Kill Process, Block Network, the platform immediately executed Kill Process, terminating PID 4244 at the kernel level.
• Zero Damage: Because the decoy files were positioned to trigger on initial directory traversals, Settra was killed in its tracks. No user files were encrypted, no ransom notes were scattered across production shares, and the attack was completely neutralized.

2. Detection Mode: Comprehensive Threat Telemetry

When operated in audit or Detection Mode, Cynet allows the execution to proceed while capturing forensic evidence across every stage of the kill chain:

Alert 1: Process Monitoring — Disabling Event Logging

• ETW Alert ID: CyAlert Heuristic Activity – Clear Windows Event Logging
• Severity: Medium | Origin: DRIVER / PH NG | MITRE: T1562.002
• Detection Details: Cynet’s heuristic engine caught the malware spawning c:\windows\system32\wevtutil.exe with command line wevtutil cl Security under High integrity (PID 9220), alerting responders to active defense impairment.

Figure 12: Cynet Detection Mode — Defense Impairment: (Top) CyAlert Heuristic Detection for Clear Windows Event Logging; (Bottom) Command-Line Process Trace (wevtutil.exe cl Security)

Alert 2: Unauthorized File Operation — Ransomware Overwrite Activity

• ETW Alert ID: IOF – Ransomware Suspicious Exec Overwrite Data Files – v2 – TH
• Severity: Critical | Origin: DRIVER / IOFilter | MITRE: T1486
• Detection Details: Cynet detected the unsigned executable (_win64.exe –path c:\ –cmd, PID 4232) performing rapid overwrite operations across the filesystem, generating files with the temporary .locked_wip extension (e.g., python.tiff.locked_wip).

Figure 13: Cynet Detection Mode — Mass Overwrite: (Top) IOF Alert for Suspicious Executable Overwriting Data Files; (Bottom) File Indicators Showing Rapid .locked_wip Extension Generation

Alert 3: Unauthorized File Operation — Ransomware Note Found

• ETW Alert ID: IOF – Ransomware Note Found
• Severity: Critical | Origin: DRIVER / IOFilter | MITRE: T1486
• Detection Details: Cynet’s file monitoring engine identified the creation of RESTORE_FILES.txt across user and test directories. The alert captured high file-counter activity (532 files) and untrusted certificate status (NotSigned).

Figure 14: Cynet Detection Mode — Ransom Note Drop: (Top) IOF Alert for Ransom Note Creation (532 Files Affected); (Bottom) File Indicators Tracking RESTORE_FILES.txt Across Directories

Alert 4: Unauthorized File Operation — Decoy Files Touched

• ETW Alert ID: IOF – Ransomware Activity Detected – Decoy Files – Unsigned Processes – TH
• Severity: Critical | Origin: DRIVER / IOFilter | MITRE: T1486
• Detection Details: Demonstrates Cynet’s decoy engine in action under detection-only monitoring. The unsigned ransomware was tracked attempting write operations on decoy image files (e.g., 50.jpg.locked_wip) inside the protected canary directory \! Protection(DON’T DELETE)\….

Figure 15: Cynet Detection Mode — Deception Telemetry: (Top) IOF Decoy Files Alert for Unsigned Process; (Bottom) Target Path Trace in Honeypot Protection Directory (50.jpg.locked_wip)

3. Laboratory Execution Trace

To confirm the static reverse engineering findings against live execution telemetry, Settra was detonated in an isolated FLARE analysis VM running Cynet monitoring: