home / malware

Malware Research

Specimens I write myself, taken apart in an isolated lab: static and dynamic analysis, binary internals, and the detection logic that follows from the behaviour they actually exhibit.

publication policy isolated research range

At a glance

Specimens: Self-authored and non-operational, or benign laboratory samples. Nothing destructive, nothing that propagates without a deliberate act, and no third-party malware.
Method: Static analysis, dynamic analysis, disassembly and debugging, behavioural observation, and memory and network artefact examination.
Environment: Disposable guests in a default-deny range with no route out and no real data, reverted to a clean snapshot after every run. See the isolated research range.
Published: Sanitised excerpts, observations, detection rules and metadata. Never a runnable sample or a working payload, per the sanitization policy.
Archive: Generated at build time from each case study's own front matter, so the list below cannot drift from the studies it describes.

Research categories

three tracks · one method

Malware development and internals

How a specimen is built and what it becomes on disk and in memory: executable formats and binary structure, process and memory behaviour, operating-system interactions, and controlled experiments with techniques such as persistence in a scope that is deliberately narrow.

Malware analysis and reverse engineering

Taking observed behaviour back to the code that causes it: disassembly and debugging, control flow and strings, imports and syscalls, process trees, memory residency, and network artefacts, with the reasoning recorded as it was made.

Detection engineering and defensive research

What the behaviour looks like to a defender: YARA and Sigma rules, telemetry queries, behavioural indicators, ATT&CK mappings, and the false positives, blind spots and coverage limits of each rule.

No case studies are published yet. A study appears here only once it has been run in the lab and written up, so the archive stays empty rather than filling with entries that describe work that was not done. The three categories above are where the entries will land.

How a case study is written

evidence over assertion

Every claim in a case study carries the strength of the evidence behind it, so a reader can tell observation from interpretation without having to trust the prose:

FACT read directly from a record that is published with the write-up.
CORROBORATED seen in two or more independent records that agree.
INFERENCE the most economical reading of the evidence, stated as a reading and not as an observation.
HYPOTHESIS plausible, not yet tested, and left open on purpose.
DISPROVEN tested and rejected. Kept, because a negative result constrains the conclusion.
BENIGN real activity that looks suspicious and is not malicious. Kept, because it is the first false positive of any rule built on the same signal.
UNRESOLVED something the evidence does not settle. Written down rather than guessed.

A study also has to be repeatable: the environment is described before the run, the commands are given as inert text, the captured records are shown in full (sanitised) next to the claim they support, and an artifact is only ever offered as proof of what it actually establishes.

Adding a case study

content model · one command

A case study is a normal page bundle in this section, scaffolded from the archetype so the schema and the shortcode library are already in place:

$ hugo new content/malware/<slug>/_index.md

Front matter	Value	What it drives
`title`	Study title	Page heading, card heading and `<title>`.
`description`	One sentence	Page and card summary, meta description and Open Graph.
`category`	`development` \| `analysis` \| `detection`	Which track above the study is listed under.
`status`	`template` \| `experimental` \| `in-progress` \| `complete`	The status chip on the card. `template` is a scaffold and stays out of the archive.
`tools`	List	The instruments shown on the card.
`tags`	List	The site's existing tag taxonomy: /tags/ pages and the related-content box.
`date`, `lastmod`	ISO date	Publication date, ordering, and the revision note on the card.

The page is served at /malware/<slug>/, picked up by the navigation, the sitemap, the tag pages and site search automatically, and listed above as soon as its status leaves template. There is no separate index to update.

Safety, scope and limits

Specimens and experiments cover systems I own, in an isolated range, under the authorisation that makes that work legitimate. Nothing here is run against anyone else's systems, and no real environment, credential or indicator appears in a write-up.
What is published is the analysis: excerpts, observations, detection logic and metadata. Downloadable artifacts are limited to rules and benign test fixtures, never a runnable specimen or a weaponised payload.
Anything shown as an excerpt stays inert: binary fragments, logs and suspicious strings are rendered as text and are not executable from the page.
A study describes one specimen under one set of conditions. Behaviour that depends on a build environment, an operating-system version or a detection product will differ elsewhere, and each study says where its own confidence stops.
If something here could be misused or identifies you or your organisation, the contact form is the fastest way to have it reviewed.

The lab this runs in →Detection rules →Sanitization policy →