Case study · Sample Analysis
Analysis of a Malicious Loader Disguised as a WinRAR Installer
You are an operator handling a disguised-installer alert, holding only a SHA256 and the requirement to lay out the whole drop logic clearly: what each of the three BATs dropped by the EXE does, what they drop next, and what the final core payload is. Work through this article and you will receive an analysis report with a full attack map, an attack-chain timeline, a complete IOC list and a cleanup plan, with the threat level rated Critical.
PE32+ · x86-64 · packaged with Setup Factory· Disguised as WinRAR · full installer embedded in the resource section · entropy 7.93· Landi N2.5· Full analysis report · attack map + IOC list + detection and cleanup plan· Threat level Critical
Session replays & reports are original records in Simplified Chinese · Built with AVL Code + the Landi model
Overview
- 01
Submit and identify — the Setup Factory disguise closes the loop
You hand AVL Code the SHA256 together with "a complete analysis report + clarify the drop logic" in one sentence, and get the sample verdict first: a PE32+ loader disguised as winrar-x64-700.exe, with the real WinRAR installer embedded in its resource section.
- 02
Drop-chain reconstruction — three BATs and a two-layer scheduled task unfold layer by layer
The report gives each of the three BATs you named its size, landing path and execution logic verbatim; the two-layer scheduled-task persistence chain (boot trigger + 5-minute keep-alive) and all 4 hosts-file hijack entries land in tables.
- 03
Payload verdict and delivery — the a.ps1 backdoor + complete IOCs + cleanup plan
The final payload a.ps1’s four-module architecture, 5-second polling and UID binding are reconstructed; the IOCs form a table with detection rules and cleanup steps attached. You ask for the MD, and one interface timeout is honestly recorded in the delivery step.
Task for AVL Code
02b6cecf0dedfaab4e8491345ad99f125a802257f3c1e28f66f65491f1584004 Produce a complete analysis report for me, covering the overall drop logic. Make this logic clearer — for example, the sample EXE drops three BATs, each BAT’s core function. What does it drop next, and what is the final core payload?Prerequisites: AVL Code is logged in; the sample is provided by hash (only the hash is shared publicly for this case); in the session export this round’s "8 thinking passes · 19 tool calls" were folded into a compact line, so the tool-call trail cannot be replayed call by call
Reproduction materials at the end of this article Try it yourself ↓
Sample Identification
The task assignment is a single sentence — hand over the hash, ask for a complete analysis report, and name the drop logic explicitly. No analysis outline, no sandbox; next, watch how it walks from this instruction to the verdict:
02b6cecf0dedfaab4e8491345ad99f125a802257f3c1e28f66f65491f1584004 Produce a complete analysis report for me, covering the overall drop logic. Make this logic clearer — for example, the sample EXE drops three BATs, each BAT’s core function. What does it drop next, and what is the final core payload?Loads the analysis tools; 19 tool calls in this round cover the full picture
→ Basic info: winrar-x64-700.exe · PE32+ · packaged with Setup Factory
→ A complete WinRAR installer embedded in the resource section · overall entropy 7.93 (encrypted/compressed payload)
→ Attack map: sample EXE → once.bat → connectionupdate2.bat → connectionupdate.bat → a.ps1, five layers deep
→ Threat level: CriticalDrop-Chain Reconstruction
This is the section your instruction named explicitly (quoted verbatim):
For example, the sample EXE drops three BATs, each BAT’s core function. What does it drop next, and what is the final core payload?Reconstructs each BAT in turn (size / landing path / execution logic):
→ once.bat: creates the scheduled task (SYSTEM · boot trigger · highest privileges) → triggers once immediately → self-deletes
→ connectionupdate2.bat: triggers the next-level task every 5 minutes
→ connectionupdate.bat, three moves: Defender-excludes System32 → appends 4 hosts entries → downloads a.ps1 and runs it in memory
→ Obfuscation: Base64 encoding + string substitution
→ Full attack-chain timeline T+0s → T+20sFinal Payload
The question "what is the final core payload" gets a whole chapter in the report:
What does it drop next, and what is the final core payload?a.ps1’s four-module architecture: UID management (registry + file dual backup) / C2 communication (polls get-command.php every 5 seconds) / command-execution engine (runs delivered PowerShell directly) / anti-detection (SessionId check + Defender-exclusion re-confirmation)
→ Download sources: 157.173.104.143 (primary) · issue.homes (backup, via hosts hijack)
→ IOCs: 5 file hashes · 2 C2 addresses · 4 hijacked domains · 2 scheduled-task names · 2 registry paths
→ 5 detection rules + 6 cleanup steps (kill process → delete tasks → delete BATs → delete UID storage → restore hosts → revoke exclusions)Delivery Confirmation
The report was fully generated in the session; you add one line asking for it on disk — and this step does not complete as expected:
OK, save the MD file[Error: llm stream call failed: after 5 attempts: http request: Post "https://zapi.avlcode.cn/v1/delta": net/http: timeout awaiting response headers]
→ All 5 retries time out
→ A follow-up "(no text reply)"
→ The session export contains no confirmation that the MD file was ever writtenTry it yourself
Reproducing this task in AVL Code takes two messages — swap the hash for the SHA256 of your own sample, and adjust the drop-logic requirements as needed:
1) Main instruction (verbatim):02b6cecf0dedfaab4e8491345ad99f125a802257f3c1e28f66f65491f1584004 Produce a complete analysis report for me, covering the overall drop logic. Make this logic clearer — for example, the sample EXE drops three BATs, each BAT’s core function. What does it drop next, and what is the final core payload?2) Delivery confirmation (verbatim):OK, save the MD file- This case’s honest boundary: in the session export this round’s "8 thinking passes · 19 tool calls" were folded into one compact line, so the tool-call trail cannot be replayed item by item; everything in the duo right column comes from text actually visible in the session and the report chapters. After the second instruction the model interface timed out (5 retries), and the session contains no confirmation that the MD file was written; the "about 3 minutes" duration appears only in the existing case entry — the session watermarks all share one timestamp, so it cannot be independently verified. Verification-table sources A/B are the session report and the existing entry respectively, but the latter was also produced by the same session, so their mechanical independence is limited.
Next question: Put the two scheduled-task names and HKLM\Software\Wireless\uid into detection rules, then use captured a.ps1 traffic to verify the 5-second polling interval and the UID reporting format.