Listen to this Post
Introduction:
Attackers are increasingly blending legitimate software components with oversized, malformed DLLs to evade static detection. In a recently uncovered campaign, a MediaFire-hosted ZIP archive delivered a Python setup executable that side-loaded a suspiciously large python37.dll (nearly 400 MB) padded with repeated `J` bytes, leading to process injection into dllhost.exe and ultimately establishing three parallel persistence mechanisms: PowerShell, a fake EdgeUpdate scheduled task, and NetSupport RMM.
Learning Objectives:
- Analyze malformed DLLs with byte-padding techniques used to evade size-based scanning and sandbox timeouts.
- Detect process injection into dllhost.exe and trace C2 callbacks over non-standard ports.
- Hunt for multi-stage persistence (PowerShell, fake browser updaters, RMM tools) using forensic timestamps and IOCs.
You Should Know:
1. Analyzing Oversized DLLs with Byte Padding
Attackers inflated python37.dll to 400 MB using repeated `J` (0x4A) padding to hinder upload to sandboxes and evade quick static scans. This technique also masks malicious code within a sea of benign-looking repetition.
Step‑by‑step guide to analyze such DLLs on Linux/Windows:
Linux – Check size and hex patterns:
Check file size and type ls -lh python37.dll file python37.dll Dump first and last 512 bytes to spot padding xxd python37.dll | head -1 32 xxd python37.dll | tail -1 32 Count repeated J bytes (0x4a) across the file hexdump -C python37.dll | grep -c "4a 4a 4a" Extract non-padding regions (e.g., after 100MB of J's) dd if=python37.dll of=suspicious_code.bin bs=1M skip=380 count=20 strings suspicious_code.bin | grep -E "http|.exe|powershell|C2"
Windows – Using PowerShell and Sysinternals:
Get file hash and size
Get-FileHash python37.dll -Algorithm SHA256
(Get-Item python37.dll).Length / 1MB
Read raw bytes to check padding pattern
$bytes = [System.IO.File]::ReadAllBytes("python37.dll")
$first100 = $bytes[0..99] -join ','
$last100 = $bytes[-100..-1] -join ','
Write-Host "First 100 bytes: $first100"
Write-Host "Last 100 bytes: $last100"
Use strings.exe from Sysinternals to find URLs
strings64.exe -1 8 python37.dll | findstr /i "http:// https:// 138.124"
Why it matters: Traditional AV scans may timeout on 400 MB files; defenders should cap scan time and use byte-frequency analysis to flag uniform padding.
2. Detecting Process Injection into dllhost.exe
The malware injected into `dllhost.exe` (a legitimate COM surrogate) which then beaconed to 138[.]124[.]186[.]2:7000. This bypasses basic parent-child process rules.
Step‑by‑step detection with Sysmon and PowerShell:
Configure Sysmon to log remote thread creation (Event ID 8):
<Sysmon schemaversion="4.22"> <EventFiltering> <RuleGroup name="ProcessInjection" groupRelation="or"> <CreateRemoteThread onmatch="include"> <TargetImage condition="end with">dllhost.exe</TargetImage> <SourceImage condition="contains">setup.exe</SourceImage> </CreateRemoteThread> </RuleGroup> </EventFiltering> </Sysmon>
PowerShell hunting for suspicious dllhost.exe network connections:
Query event logs for dllhost.exe outbound connections on port 7000
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; ID=3} |
Where-Object {$<em>.Message -match "dllhost.exe" -and $</em>.Message -match "7000"} |
Select-Object TimeCreated, Message -First 20
Check for dllhost.exe with unexpected command line (should be empty)
Get-Process -1ame dllhost | Select-Object Id, StartTime, CommandLine
Use netstat to see live connections
netstat -ano | findstr "7000" | findstr "dllhost"
Memory forensics (Volatility 3) to confirm injection:
List processes and find dllhost.exe PID vol3 -f memory.dump windows.psscan | grep dllhost Dump injected PE from dllhost's memory space vol3 -f memory.dump windows.malfind.Malfind --pid <PID> --dump
3. Hunting PowerShell & Fake EdgeUpdate Persistence
The actor installed a PowerShell backdoor and created a scheduled task mimicking `MicrosoftEdgeUpdateTaskUserUA` pointing to a fake pythonw.exe.
Step‑by‑step detection and removal:
List scheduled tasks with EdgeUpdate in name:
PowerShell - find suspicious EdgeUpdate tasks
Get-ScheduledTask | Where-Object {$_.TaskName -like "EdgeUpdate"} |
Select-Object TaskName, State, TaskPath, Actions
Check task action details
$task = Get-ScheduledTask -TaskName "MicrosoftEdgeUpdateTaskUserUA{GUID}-SID"
$task.Actions | Format-List
Look for pythonw.exe outside legitimate EdgeUpdate paths
Get-ScheduledTask | ForEach-Object {
$actions = $<em>.Actions
if ($actions.Execute -like "pythonw.exe" -and $actions.Execute -1otlike "\Microsoft\EdgeUpdate\") {
Write-Host "Suspicious: $($</em>.TaskName) - $($actions.Execute)"
}
}
Command line (cmd) hunting:
schtasks /query /fo LIST /v | findstr /i "EdgeUpdate"
wmic scheduledtask where "name like '%%EdgeUpdate%%'" get name,command,enabled
Delete malicious task
schtasks /delete /tn "MicrosoftEdgeUpdateTaskUserUA{GUID}-<SID suffix>" /f
Check PowerShell event logs for suspicious one-liners:
Get PowerShell script blocks containing C2 domains
Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" |
Where-Object {$_.Message -match "blockrazor.xyz|gstats-api-contact.cc"} |
Select-Object TimeCreated, Message
4. Identifying NetSupport RMM Abuse as Third-Stage C2
NetSupport Manager is a legitimate remote access tool. Attackers installed it under `%APPDATA%\Microsoft\Image\SQLTool\46a05ef1a89e0c8a\century.exe` to blend in.
Step‑by‑step detection and containment:
Find all NetSupport executables outside Program Files:
Hunt for NetSupport binaries in user directories Get-ChildItem -Path C:\Users\ -Recurse -Filter "century.exe" -ErrorAction SilentlyContinue | Select-Object FullName, Length, LastWriteTime Check for NetSupport client configuration (encrypted) Get-ChildItem -Path %APPDATA%\Microsoft\Image\SQLTool\ -Recurse -Include .cfg, .key, .dat Network connections to known NetSupport C2 ports (443, 5400, 5500, 7000) netstat -ano | findstr ":5400|:5500" | findstr "ESTABLISHED"
Linux-based log analysis (if Windows logs are centralized):
Grep syslog for NetSupport process creations
zgrep -i "century.exe" /var/log/syslog | grep -i "created"
Query Zeek logs for NetSupport user-agent or SSL certs
cat conn.log | awk '{print $9}' | sort | uniq -c | sort -1r | grep -E "NetSupport|port 5400"
Mitigation: Block NetSupport domains via DNS sinkhole (e.g., bsc[.]blockrazor[.]xyz, mgo[.]gstats-api-contact[.]cc). Use AppLocker to restrict execution of RMM tools from non-admin paths.
5. DFIR Triage: Timestamp Analysis on Zipped Artifacts
The investigator noted that timestamp differences across files in the extracted ZIP helped identify the malicious DLL. This is a quick win during triage.
Step‑by‑step using PowerShell and 7zip:
Extract ZIP preserving original timestamps
7z x malicious.zip -oextracted -aos
Compare modified dates across all files
Get-ChildItem -Recurse extracted | Select-Object Name, LastWriteTime, Length |
Sort-Object LastWriteTime | Format-Table -AutoSize
Find files with significantly different timestamps (e.g., 1 hour or more apart)
$files = Get-ChildItem -Recurse extracted
$avgTime = ($files | Measure-Object -Property LastWriteTime -Average).Average
$files | Where-Object { [bash]::Abs(($_.LastWriteTime - $avgTime).TotalHours) -gt 1 }
Using Linux `stat` and `find`:
unzip malicious.zip -d extracted/ cd extracted Show all timestamps stat --printf='%n\t%y\n' / Find files modified more than 2 hours apart from a reference (e.g., setup.exe) find . -type f -1ewer setup.exe -o -older setup.exe
Forensic note: Attackers often modify timestamps (timestomping), but a ZIP archive from MediaFire or cloud storage retains original upload times; anomalies between the container and inner files reveal tampering.
- Hunting IOCs with SIEM and EDR Queries (KQL, Sigma, YARA)
Kusto Query Language (KQL) for Microsoft Sentinel:
// DNS requests to malicious domains
let MaliciousDomains = dynamic(["blockrazor.xyz", "gstats-api-contact.cc", "clickvector.tech"]);
DeviceNetworkEvents
| where RemoteUrl has_any (MaliciousDomains)
| project TimeGenerated, DeviceName, RemoteUrl, InitiatingProcessFileName
// Process injection to dllhost.exe from non-standard parents
DeviceEvents
| where ActionType == "CreateRemoteThreadApiCall"
| where TargetProcessName == "dllhost.exe"
| where InitiatingProcessName in ("setup.exe", "python.exe", "pythonw.exe")
Sigma rule for suspicious DLL side-loading:
title: Oversized DLL Sideloaded by Python Setup status: experimental logsource: product: windows service: sysmon detection: selection: EventID: 7 Image loaded ImageLoaded|endswith: 'python37.dll' Image|endswith: 'setup.exe' condition: selection filter_size: - DllSizeMB > 300
YARA rule to detect J-padded DLLs:
rule J_padded_DLL {
meta:
description = "Detects DLLs with excessive 0x4a (J) padding"
strings:
$j_pattern = { 4A 4A 4A 4A 4A 4A 4A 4A 4A 4A } // 10 consecutive J's
condition:
uint32(0) == 0x00905a4d and // MZ header
j_pattern > 10000 // At least 10k occurrences
}
- Mitigation and Hardening Against DLL Sideloading & RMM Abuse
Step‑by‑step hardening actions:
Enable DLL search order monitoring (Windows):
Set Image File Execution Options to log DLL loads reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\setup.exe" /v GlobalFlag /t REG_DWORD /d 0x00000010 Enable loader snaps via GFlags (requires reboot) gflags /p /enable setup.exe /full
Block unsigned sideloaded DLLs via AppLocker:
Create rule to allow only signed DLLs in user-writable paths New-AppLockerPolicy -RuleType Dll -User Everyone -Action Deny -Path "%USERPROFILE%\" -Except SignedBy "Microsoft"
Restrict NetSupport RMM installation via Windows Defender Attack Surface Reduction:
Add-MpPreference -AttackSurfaceReductionRules_Ids "d1e49aac-8f56-4280-b9ba-993a6d77406c" -AttackSurfaceReductionRules_Actions Enabled This ASR rule blocks process creations from PsExec, WMI, and known RMM tools
Network-level blocking (iptables/Windows Firewall):
Linux iptables to drop C2 traffic iptables -A OUTPUT -d 138.124.186.2 -j DROP iptables -A OUTPUT -d 185.76.243.85 -j DROP
Windows Firewall block rules New-1etFirewallRule -DisplayName "Block C2 138.124.186.2" -Direction Outbound -RemoteAddress 138.124.186.2 -Action Block
What Undercode Say:
- Key Takeaway 1: Attackers are weaponizing file size as an evasion technique—400 MB DLLs cause sandboxes to timeout or skip deep inspection. Defenders must implement byte-frequency analysis and cap scan times with fallback manual review.
- Key Takeaway 2: Multi-stage persistence (PowerShell → fake browser updater → RMM) indicates redundancy planning. Removing only one path leaves the door open; triage must hunt all three.
Analysis: This campaign is not a mass outbreak (yet) but a blueprint for sophisticated intrusions. The use of MediaFire as a dropper bypasses URL reputation filters that only block known malware sites. The oversized DLL padding is a clever anti-forensic tactic—most automated scanners won’t chew through 400 MB. The addition of NetSupport after two other C2 paths were in place shows the attacker wanted resilient backdoor options. Defenders should prioritize monitoring for `pythonw.exe` executions outside of legitimate Python installations and any process injecting into dllhost.exe. Timestamp comparison on extracted ZIPs is a low-effort, high-yield DFIR technique every analyst should memorize. Proactive hunting using the provided IOCs (domains, IPs, registry paths) across SIEM and EDR data will catch this chain before full deployment.
Prediction:
- -1 Over the next 12 months, threat actors will increasingly use oversized, padded binaries (500MB+) distributed via legitimate cloud storage (Dropbox, Google Drive, MediaFire) to bypass sandbox time limits, forcing SOCs to implement size-aware detection triage.
- +1 Open-source DFIR tools will soon incorporate “padding entropy” scoring as a standard indicator, enabling automated flagging of files with >80% repeated byte sequences regardless of file size.
- -1 NetSupport RMM will become a top-5 LOLBin (Living off the Land Binary) as more attackers abuse its signed executables for persistent C2, requiring Microsoft to issue specific ASR rules for RMM tools in non-default paths.
- +1 Cloud-1ative EDR solutions that perform streaming byte analysis (without full file download) will gain adoption, as they can detect padding anomalies without transferring 400 MB to the cloud.
▶️ Related Video (74% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Kostastsale We – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
