Case study · Sample Analysis
Analysis of a Disguised-Service Cryptocurrency Miner (XMRig Variant)
An operator investigating abnormal compute usage drops the SHA256 of a 64-bit suspicious file into AVL Code, and one natural-language instruction drives a pure-static deep dive: the 576 KB XMRig-variant miner disguised as a system-maintenance service is pinned down item by item — version-info forgery, scheduled-task persistence, embedded mongoose communication and process-injection imports all on record — then one follow-up line turns the report into an archived Markdown file.
AVL Code · Landi N2.5 (provided by AVL-Zero)· Windows · 576,000-byte PE32+ x86_64 (accepted on a SHA256 alone)· Pure static analysis · 25 tool calls in the first round· IOCs: 3 hashes · 4 disguised filenames · 1 C2 mailbox · 2 scheduled-task names · 1 registry path· About 14 minutes · delivered as a Markdown analysis report
Session replays & reports are original records in Simplified Chinese · Built with AVL Code + the Landi model
Overview
- 01
Static collection — a 576 KB PE32+ identified as an XMRig-variant miner
You hand AVL Code the SHA256 and the analysis requirements (determine function, write the title, IOCs, harm overview) in one pass; it collects static traits with 25 tool calls: three hashes, PE structure, compile time, entropy, strings, version info, import table.
- 02
Disguise teardown — version info and persistence mechanisms pinned item by item
You check the report’s six judgment bases one by one: InternalName and resource-section disguise, system-path landing disguise, schtasks scheduled tasks, mongoose communication, process-injection imports, registry operations.
- 03
Archive and deliver — the IOC list enters a table, the report saved as Markdown
You add one line — "produce the report as an MD file" — and the IOC table (3 hashes, 4 disguised filenames, 1 C2 mailbox, 2 scheduled-task names, 1 registry path) lands in 样本分析报告_13ab3d57_20260804.md.
Task for AVL Code
13ab3d572b30a77009d8d417be0cce6774b7590a302ac0e6f9843e1ba693a243 Analyze this file in detail for me, including determining its function and writing a title. IOCs, harm, overview, and so onPrerequisites: AVL Code is logged in and the sample file (named by SHA256) is already in the workspace; no need to execute the sample — the whole process is static analysis
Reproduction materials at the end of this article Try it yourself ↓
Static Collection
The first question in any compute-anomaly triage is always "what exactly is this file". You hand AVL Code the hash and the analysis requirements in one pass; without executing the sample it goes straight to static collection:
13ab3d572b30a77009d8d417be0cce6774b7590a302ac0e6f9843e1ba693a243 Analyze this file in detail for me, including determining its function and writing a title. IOCs, harm, overview, and so onLocates the sample by SHA256 alone (576,000 bytes) → static collection: PE32+ x86_64 · Windows GUI · compiled 2018-03-16 · entropy 6.26 with obfuscation
→ Key string evidence: "@protonmail.com -p x -t %d --donate-level=1 --nicehash" → XMRig-style command-line format
→ Delivers the verdict directly: a crypto-mining program disguised as a system-maintenance service (XMRig variant)Disguise Teardown
Your instruction said "determine its function and write a title", and AVL Code pins the function and the disguise mechanism down with six judgment bases, each one checkable against the report:
Including determining its function and writing a title. IOCs, harm, overview, and so onBasis 1 mining traits: --donate-level=1 --nicehash → XMRig-style parameter format
Basis 2 service disguise: InternalName = MaintenanceServices.dll · landing-path disguise as Svchost.exe / ServicesHost.exe / spoolsv.exe · version info forged as Microsoft Corporation
Basis 3 persistence: schtasks creates the \Microsoft\Windows\UPnP\Services scheduled task
Basis 4 network: WININET + WS2_32, embedded mongoose (HTTP / WebSocket / TLS)
Bases 5/6 process-thread and registry-operation APIs all present
→ Title settled: a crypto-mining program disguised as a system-maintenance service (XMRig variant)Report Archived
A verdict scattered through the conversation cannot enter a ticket yet; you add one colloquial follow-up that collects the results into a single file:
Has the report been produced as an MD file? Mining-sample analysisWrites the Markdown report → 样本分析报告_13ab3d57_20260804.md
→ Chapter list: basic info · function verdict (6 bases) · IOC table · 5-item harm overview · technical details · conclusion
→ IOCs: 3 file hashes · 4 disguised filenames · C2 mailbox @protonmail.com · mongoose · hard-coded DNS 8.8.8.8:53 · 2 scheduled-task names
→ Ready for reporting or archiving as-isTry it yourself
Reproducing this case takes two instructions: import the session into your workspace to replay it, or follow along in your own AVL Code — swap the placeholders for your sample’s hash:
› <sample SHA256> Analyze this file in detail for me, including determining its function and writing a title. IOCs, harm, overview, and so on (once the verdict is in, follow up with)› Has the report been produced as an MD file? Mining-sample analysis- The first instruction already carries the output requirements (function, title, IOCs, harm overview), so paste it as-is; the second colloquial follow-up triggers archiving just the same. This case’s session export is the summarized variant and the first round’s per-call tool traces were not retained, so your tool sequence on replay may differ in order — the static conclusions will be identical. Full IOC details and the harm-overview text live in the case report report.pdf and the session export.
Next question: With the report and IOC list in hand, the natural next step is remediation — how do you clean up the two scheduled tasks \Microsoft\Windows\UPnP\Services and TcpipReportingServices, delete the 4 disguised landing files, and turn the disguised filenames and hashes into EDR detection rules?