From Synthetic Tests
to Real Malware
Lab 010 documented how Ladon was built — the detection modules, the architecture decisions, the scoring logic. It ended with a straightforward observation: synthetic test files tell you the code runs. Real malware tells you the detection logic actually works. This lab is that test.
The five samples analyzed here were sourced from MalwareBazaar and one live phishing attempt that arrived in my own inbox. All five triggered Ladon's polyglot detection module, and none were safe to open. A later re-analysis (see the Correction section immediately below) found that the polyglot finding was a false positive: three samples are genuinely malicious PDFs, one is HTML masquerading as a PDF, and none is actually a polyglot. The original findings are preserved below with that correction in mind.
The goal of this lab is not to reverse-engineer the malware — Ladon is a triage tool, not a malware analysis platform. The goal is to document what the tool found, what those findings mean, and what would have happened to a non-technical user who opened any of these files.
On sample handling: All analysis was performed using Ladon's static analysis engine. No file was executed, opened in a PDF viewer, or processed by any renderer. Ladon reads raw bytes only. Four samples were sourced from MalwareBazaar. One arrived as a live phishing email. Hashes are included for reference. The files themselves are not distributed.
Correction — What the Bytes Actually Show
Three months after publishing this lab, I re-examined the samples byte-by-byte to check the original findings against a second method. They did not hold up. The “polyglot — embedded Windows PE” finding reported for all five samples was a false positive from an early detection check that flagged any MZ byte-pair as an executable. This section documents what the re-analysis found. The samples remain genuinely malicious; the polyglot characterization is retracted.
Step 1 — Is there actually a Windows PE inside these files?
A real Windows executable contains the signature bytes PE\0\0 (50 45 00 00). If these were genuine PDF-PE polyglots, that signature would be present. It is not, in any of them:
$ for f in *.pdf; do echo -n "$f: "; grep -c -a -F $'PE\x00\x00' "$f"; done d67e62bb…pdf: 0 e2b75bae…pdf: 0 b046d04b…pdf: 0 5095c647…pdf: 0 → Zero PE signatures. None of the samples contains a Windows executable. The "PE at offset X" findings were incidental MZ bytes, not real PEs.
Step 2 — Sample 04 (Gamaredon) is not even a PDF
The sample originally described as a “clean PDF carrying an embedded executable” is not a PDF at all. Its first bytes are an HTML declaration; its body is VBScript:
$ head -c 48 5095c647…pdf | xxd 00000000: 3c21 444f 4354 5950 4520 6874 6d6c 3e0d <!DOCTYPE html>. 00000010: 0a3c 6874 6d6c 3e0d 0a3c 6865 6164 3e0d .<html>..<head>. 00000020: 0a3c 7363 7269 7074 2074 7970 653d 2274 .<script type="t $ file 5095c647…pdf 5095c647…pdf: HTML document text, ASCII text → Sample 04 is HTML/VBScript wearing a .pdf extension — a masquerade, not a polyglot. A genuine HTML-smuggling dropper, but the file type itself was mischaracterized in the original analysis.
Step 3 — What the current tool says
Re-running the samples through the current document_triage.py (with the structural PE validation added April 30) confirms the polyglot false positives are gone. The genuine PDFs are still correctly flagged for their real indicators — auto-execute actions, callback URIs, live C2:
$ python3 document_triage.py b046d04b…pdf # Facebook phish [ POLYGLOT / FILE TYPE CHECK ] PASS — no polyglot indicators Severity : CRITICAL # via /AA auto-execute + /URI $ python3 document_triage.py e2b75bae…pdf # ValleyRAT [ POLYGLOT / FILE TYPE CHECK ] PASS — no polyglot indicators Severity : CRITICAL # via /URI + live Tencent Cloud C2 → Still caught. They were malicious documents all along — just not polyglots. The PDF-structure and URL modules did the real work.
Step 4 — Testing against real polyglots
To validate polyglot detection properly, I tested the current tool against the Polydet corpus of verified polyglots (largely from POC||GTFO / Corkami). Unlike the original samples, these are genuine polyglots — and the tool flags them:
$ file EXE+HTML+PDF-1.pdf EXE+HTML+PDF-1.pdf: PE32 executable (console) Intel 80386, for MS Windows $ python3 document_triage.py EXE+HTML+PDF-1.pdf !! HIGH Extension .pdf suggests PDF but magic bytes indicate PE_EXE !! HIGH PDF signature found at offset 64 inside file $ python3 document_triage.py PDF+ELF-1.pdf Severity : CRITICAL # ELF-first polyglot, caught → Real PE and ELF polyglots ARE detected. The tool's logic works — the original error was in the samples, not the detection approach.
What this correction reflects. The five samples were genuinely malicious and were flagged as dangerous — that held. What did not hold was the specific claim that they were polyglots carrying embedded Windows executables: byte-level re-analysis shows no PE in any of them, and one sample was not a PDF at all. The lesson: validate a file’s actual type before running format-specific checks, and confirm a finding against the raw bytes before publishing it. The original sample-by-sample write-up is retained below for transparency, with the polyglot findings marked retracted.
The Samples — What Ladon Found
Each sample is presented with its Ladon report findings, what those findings mean in practice, and what a non-technical user would have experienced if they had opened the file.
.msi and .exe hosted on Tencent Cloud, active at time of analysis. Direct links to secondary payloads on cos.ap-guangzhou.myqcloud.com, including lnstaller.msi — deliberate misspelling of "installer" to evade string-based detection./AA key triggers code execution automatically on page open, page close, or document print — no user interaction required beyond opening the file.maneger-accouintr-solutieonst.site — Deliberate misspelling of "manager account solutions" on a .site TLD. A throwaway phishing domain designed to pass a visual scan..pdf extension (see Correction above): a masquerade, not a polyglot. Genuinely malicious as an HTML-smuggling dropper, but the file type was mischaracterized.This is the sample that validated the intended use case for Ladon — a real phishing email, a real target, a payload that passed Gmail. Ladon caught it on first scan.
The Pattern Across All Five
[Corrected] The original version of this section claimed every sample was a polyglot carrying an embedded Windows PE. That was wrong (see the Correction section above): none of the samples contains a Windows PE, and one is not even a PDF. What the samples actually share is that they are malicious documents that evade surface-level scanning through PDF-native techniques — auto-execute actions, callback URIs, C2 domains — and, in one case, through file-type masquerade. The corrected summary below reflects what each sample actually is.
| Sample | Attribution | Actual Type | Polyglot? | Real Malicious Indicators |
|---|---|---|---|---|
| d67e62bb… Unknown dropper |
Unknown | Genuine PDF | No | /ObjStm object-stream obfuscation |
| e2b75bae… ValleyRAT / SilverFox |
Chinese APT | Genuine PDF | No | /URI ×20, live Tencent Cloud .msi + .exe C2 |
| b046d04b… Facebook phishing |
Unknown | Genuine PDF | No | /AA ×6 auto-execute, /URI ×4, typosquatted .site |
| 5095c647… Gamaredon loader |
Russian APT (FSB) | HTML/VBScript | No | HTML-smuggling dropper; spoofs .pdf extension |
| Opportunity_ Job scam · live catch |
Unknown | Unverified | Unverified | Genuine phishing email; passed Gmail |
What actually holds up: The malicious nature of these samples was real, and Ladon's PDF-structure and URL modules correctly flagged the genuine indicators — auto-execute actions, callback URIs, live C2 domains, and typosquatted infrastructure. What did not hold up was the polyglot/embedded-PE claim, which was a detection artifact. Ladon is effective at catching malicious documents through their real behavioral signals; it was the polyglot module specifically that produced false positives, and it has since been rebuilt with structural validation.
The real lesson: The Gamaredon sample — originally the “cleanest” and most alarming case — turned out not to be a PDF at all, but HTML masquerading as one. A detector must validate a file's actual type before running format-specific checks, or it will both miss the real technique (HTML smuggling) and invent a fake one (a polyglot that isn't there). This single sample reshaped how I approach file-type validation in Ladon.
What This Validates About Ladon
The detection methodology in Ladon was built from reading threat reports and file format specifications. These five samples were the first test against files that weren't constructed to test the tool — and that test surfaced both a strength and a flaw.
What worked: The URL analysis module correctly flagged the live Tencent Cloud C2 URLs in sample 2 and the typosquatted domain in sample 3. The PDF structure module correctly identified the auto-execute actions in sample 3 and the object-stream obfuscation in sample 1. These are real detections of real malicious behavior. What failed: the polyglot module reported embedded executables that do not exist — a false-positive class I only caught by re-examining the samples byte-by-byte months later. Reporting both honestly is the point of the correction above.
The live phishing sample is still the most meaningful data point — a real phishing email, sent to a real target, that passed Gmail's scanner. That is unchanged and genuine. What is retracted is the specific claim that Ladon “caught the embedded PE”: that finding came from the flawed check, and the sample is no longer available to verify. The durable point is that a tool reading raw bytes before a user opens an attachment is the right idea.
The intended use case, restated honestly: Ladon was designed for a specific scenario — a non-technical employee who receives an unexpected attachment and has no way to know if it is safe to open. The job-scam email is exactly that scenario, and it passed Gmail's scanner. The principle — read the raw bytes before anyone opens anything — is sound. This lab's error was not in the principle but in overstating what a specific (and buggy) module found.
Detection Improvements — April 30, 2026
Following the original publication of this lab, two issues were identified through continued testing and addressed with updates to document_triage.py. Both fixes are documented here with validation results.
The problem: Ladon's polyglot detection was producing false positives on large legitimate PDFs — corporate threat intelligence reports, technical manuals, and similar documents were occasionally triggering a CRITICAL finding when no malicious content was present. The issue was specific to files with heavily embedded binary content such as fonts, images, and color profiles.
The fix: The PE detection logic was updated to require a higher confidence threshold before flagging a finding. A file must now satisfy multiple structural validation checks before a Windows executable signature is reported. Incidental byte patterns that are not part of a real executable no longer trigger the module. The change was validated against both clean and malicious samples to confirm zero false negatives.
Re-test output — 2026-04-30 21:24 UTC
File: e2b75baeb7ed21fb8f27984f941286770d1c3c0b60fce8d7fa5b167bd24ba6dc.pdf · 158.4 KB · Severity: CRITICAL
Polyglot Detection — 1 finding
[CRITICAL] Windows PE (EXE) signature found at offset 4937 inside PDF file ← retracted, false positive
PDF Structure Analysis — 6 issues
[Critical] /URI detected (20×) — External URI reference
[Warning] https://6-1321729461.cos.ap-guangzhou.myqcloud.com/lnstaller.msi
[Warning] https://00-1321729461.cos.ap-guangzhou.myqcloud.com/24-12-13uninstall.exe
[Warning] http://www.baidu.com
URL Analysis — 13 suspicious URLs
Tencent Cloud COS domains (cos.ap-guangzhou.myqcloud.com) flagged MEDIUM — live Chinese APT C2 infrastructure confirmed at time of original analysis. Note: URL scoring for Chinese cloud infrastructure is a known improvement area — these domains warrant CRITICAL given attribution context.
The problem: Ladon's calendar invite analysis was incorrectly flagging two categories of legitimate calendar invites as CRITICAL meeting platform spoofs. Invites scheduled through third-party scheduling platforms were being flagged because they reference meeting platform names without routing directly through those platforms. Additionally, calendar invites forwarded through corporate email security gateways were being flagged because those gateways rewrite URLs before delivery, making a legitimate Zoom or Teams link appear to come from an unrecognized domain.
The fix: The calendar analysis module was updated to recognize both categories correctly. Legitimate scheduling platforms and known corporate email security gateways are now handled appropriately, passing clean instead of triggering false spoof alerts. Actual attacker-controlled domains that impersonate meeting platforms — the core detection target — are unaffected and still trigger CRITICAL.
On the BlueNoroff campaign context: The fake Zoom test case was modeled on a documented active campaign. Arctic Wolf reported in April 2026 that BlueNoroff — a Lazarus sub-group tied to North Korea's Reconnaissance General Bureau — was using Calendly invites that later swap to typosquatted Zoom or Teams links to deliver second-stage malware via a fake SDK update prompt. The campaign was independently covered by GovInfoSecurity, Dark Reading, Infosecurity Magazine, and CyberSecurityNews between April 17–28, 2026, and is tracked under UNC1069 and Sapphire Sleet. The fix correctly allows legitimate Calendly scheduling through while catching the attacker-controlled destination domain substitution.
Active Campaign IOCs — April 2026
The following indicators were submitted to ThreatFox on April 8, 2026 and are consistent with the BlueNoroff/UNC1069 fake Zoom campaign. Domains are defanged — brackets replace dots to prevent accidental navigation. These domains would trigger Ladon's ICS analysis if embedded in a calendar invite LOCATION or DESCRIPTION field.
| Defanged Indicator | Type | Pattern |
|---|---|---|
| usz00mczyiee[.]store | DOMAIN | Zero substitution in "zoom" — usz00m vs zoom |
| zoominviteeees[.]de | DOMAIN | Extra characters appended to "zoom" + unusual TLD |
| googlemeet[.]emilychart[.]xyz | DOMAIN | "googlemeet" as subdomain of unrelated domain + .xyz TLD |
| simplicity-w[.]pages[.]dev | URL | Cloudflare Pages abuse — legitimate infrastructure, malicious content |
What Ladon catches vs. where its boundary is: If any of these domains appeared in a calendar invite LOCATION or DESCRIPTION field, Ladon would flag CRITICAL — suspicious TLD, platform keyword in wrong domain, or typosquat pattern. What Ladon does not catch is the browser-based payload delivery stage: the fake meeting room rendering pre-recorded video, the fake audio failure, and the ClickFix "SDK Update" prompt that delivers the actual malware. That stage happens in the browser after the user clicks the link. Ladon is a pre-click triage tool — it catches the lure before it is opened. Detecting the browser-based stage requires endpoint behavioral detection or DNS-layer blocking, not static file analysis.
All five original malicious samples were re-tested after both fixes. Zero false negatives — every confirmed malicious file still fires at the correct severity. Zero false positives introduced — clean files that previously triggered incorrectly now pass clean.
The addition: Windows shortcut (.lnk) files are a documented primary delivery mechanism in phishing campaigns — including the calendar-themed BlueNoroff attacks analyzed in this lab. Ladon previously had no support for this file type. A new static analysis module was added that reads the LNK binary structure and checks for suspicious execution patterns without opening or executing the file.
What it detects: Living-off-the-land binaries (LOLBINs) — system utilities like forfiles.exe, mshta, certutil, and rundll32 that attackers use to execute payloads while evading detection rules tuned for PowerShell. Also detects UNC network paths pointing to attacker infrastructure, double extensions disguising executables as documents, and suspicious target directories.
Analysis output — June 5, 2026
File: b8d97d29e99e1f96e06836468db56855dc09305e3ed663c720fe700ea4bf6e73.lnk · 3.2 KB · Severity: HIGH
LNK Shortcut Analysis — 1 finding
[CRITICAL] Forfiles.exe detected — Windows LOLBIN used to execute commands and bypass detection
Polyglot Detection — Pass
File type consistent — no polyglot indicators. Magic bytes match the declared file extension.
On calendar invite testing: The ICS analysis module was validated using synthetic test cases modeled on documented BlueNoroff campaign IOCs — a Calendly invite to confirm no false positive, and a typosquatted Zoom domain to confirm correct detection. Real malicious ICS lure files are rarely submitted to public malware repositories — attackers submit the payload, not the invite. Synthetic tests validate that the detection logic runs correctly against known patterns. Production validation of the calendar module against real attacker-crafted invites requires a mail flow deployment — the next phase of development.
The Full Picture
Corrected: The original version of this section claimed “zero false negatives and zero false positives.” That does not survive scrutiny — the polyglot module produced false positives on every sample in this lab, and separately misses HTML files masquerading as PDFs unless the newer masquerade check is applied. What is accurate: Ladon's PDF-structure, URL, and calendar modules reliably flag genuine malicious indicators, and the April 30 work reduced real sources of noise. An honest capability audit — including validation against a verified polyglot corpus (see Correction) and the limits of each module — is the subject of the revision in progress.
The tool does not execute anything. It does not require network access. It reads raw bytes and reports what it finds — which is exactly what is needed before anyone opens an unexpected file.