AVL Code
All cases
#018 · Sample Analysis

Case study · Sample Analysis

Analysis of a Malicious Loader (cspsvc.exe)

You are an operator handling a suspicious Windows-service alert, holding only a sample hash and two requirements: produce a detailed analysis report and save it as an MD file. Work through this article and you will receive a 7.5 KB, 10-chapter Markdown analysis report — a .NET service-loader verdict, complete IOCs, a detection-and-cleanup plan, a four-dimension risk assessment, and one honest boundary: the second-stage script cspsvc.ps1 was not shipped with the sample and is listed only as a target to capture next.

PE32 · .NET · 6,656 bytes (~6.5 KB)· Pure static · sample never executed· Landi N2.5· Markdown report 7.5 KB · 10 chapters· IOCs + detection-and-cleanup plan + four-dimension risk assessment

View session Download session archive Import into your AVL Code workspace to replay the full conversation View report

Session replays & reports are original records in Simplified Chinese · Built with AVL Code + the Landi model

Overview

  1. 01

    Static identification — a 6.5 KB .NET Windows-service loader emerges

    You hand AVL Code the sample SHA256 and both requirements in one sentence; pure static analysis reads the sample through and reconstructs the multi-stage architecture that loads an external PowerShell script on service start/stop.

  2. 02

    Report on disk — a 7.5 KB, 10-chapter Markdown file ready to archive

    You add one confirmation line and receive the Markdown report already written to the workspace: IOCs, detection-and-cleanup plan and a four-dimension risk assessment complete, with the stage-two script honestly marked as still to be captured.

Task for AVL Code

c765ba5eedcd87b6f98eb503df640f5a8b077d3a30f02c6019feec1b5a553981 Analyze this program for me, write a detailed analysis report, and save it as an MD file

Prerequisites: AVL Code is logged in; the sample is in the workspace as a file (only the hash is shared publicly for this case); writing the report requires a writable workspace — the VirusTotal lookup returned nothing during the session because it was not configured, so the verdict rests entirely on the sample’s static content

Reproduction materials at the end of this article Try it yourself ↓

Static Identification

The task assignment is a single sentence — hand over the hash, ask for a detailed report, save it as an MD file. No analysis plan, no environment setup; next, watch how it walks from that instruction to a verdict:

You type → AVL Code 
c765ba5eedcd87b6f98eb503df640f5a8b077d3a30f02c6019feec1b5a553981 Analyze this program for me, write a detailed analysis report, and save it as an MD file
AVL Code runs → you see
Confirms the sample exists (6,656 bytes)
→ A special-character path blocks one route after another: fs.list parsing fails / sec.* tools blocked / command-line copy blocked → finally reads the whole file via fs.read + analyzes it in Python
→ File header: MZ + BSJB → a .NET program (CIL)
→ Key strings: cspsvc.exe · .NET 2.0 · PDB path System32\drivers\cspsvc.pdb · imports SetServiceStatus
→ Service start/stop command verbatim: PowerShell -ExecutionPolicy Bypass calling cspsvc.ps1 -SCMStart / -SCMStop
→ VT not configured → completes the verdict from the extracted information alone

Report Delivery

The report is generated within the first instruction; you add one confirmation line and receive the full delivery list:

You type → AVL Code 
Is the analysis done? Produce the analysis report
AVL Code runs → you see
fs.read re-reads and confirms the report is complete → delivers 样本分析报告_cspsvc_20260729.md (7.5 KB, 10 chapters)
→ Core verdict: cspsvc.exe is a .NET service trojan/loader disguised in System32\drivers\ — service persistence + Bypass loading of an external script, a first-stage component of a multi-stage attack
→ Risk note: the actual payload lives in cspsvc.ps1, which was not shipped with the sample; stage-two behavior is marked "possible" per loader design patterns only — no speculation beyond the evidence

Try it yourself

Reproducing this task in AVL Code takes two messages — swap the hash for the SHA256 of your own sample, and adjust the report requirements as needed:

View session Download session archive Import into your AVL Code workspace to replay the full conversation View report 
1) Main instruction (verbatim):
c765ba5eedcd87b6f98eb503df640f5a8b077d3a30f02c6019feec1b5a553981 Analyze this program for me, write a detailed analysis report, and save it as an MD file
2) Delivery confirmation (verbatim):
Is the analysis done? Produce the analysis report
  • This case’s honest boundary: the PowerShell script cspsvc.ps1 was not shipped with the sample, and second-stage behavior is marked "possible" per loader design patterns in both the session and the report — no speculation beyond the evidence. Both sources for verification-table item 4 come from this same session export (the report was generated by that session), so they do not constitute mechanically independent dual-source verification. The VirusTotal query returned nothing during the session because it was not configured; the verdict carries no cloud-verdict corroboration.

Next question: Once cspsvc.ps1 is captured, feed it through the same analysis pipeline with the same instruction to complete the stage-two attack chain and the full IOC list.