Malware Intelligence (MALINT): Intelligence Discipline Guide

A malware sample is a confession. It documents what its author wanted, how they build software, and where they expect to be contacted.

What Malware Intelligence is as a discipline

Malware intelligence is the acquisition, analysis and classification of malicious code to derive defensive value. It combines static examination of file structure, imports, strings, embedded configuration, compiler artefacts and signing certificates with dynamic execution in instrumented sandboxes that record process, file, registry and network behaviour. Deeper work involves unpacking, deobfuscation and reverse engineering to extract configuration blocks, encryption keys and command-and-control logic. Output includes detection signatures, extracted infrastructure, capability assessments and family attribution grounded in code rather than vendor labels.

Practice tiers from triage, meaning hash lookup, detonation and family classification, through configuration extraction at scale, to full reverse engineering of novel loaders and protocols. Sub-methods include YARA rule development for retro-hunting, code-similarity analysis linking families and developers, and emulation of command-and-control protocols to enumerate live infrastructure. It feeds cyber intelligence with techniques, domain and network intelligence with infrastructure, and actor intelligence with durable toolmarks.

Why it matters

Only malware analysis answers what a sample can actually do and what it talks to. Vendor labels are inconsistent and frequently wrong; observed behaviour is ground truth. Extracted configurations yield command-and-control servers, campaign identifiers and encryption keys that no feed will supply and that sometimes enable decryption or victim identification. Code reuse across samples is among the most durable attribution signals available, surviving the infrastructure churn that defeats indicator-based tracking within days.

What analysts actually look for

These are the concrete, observable signals that carry weight in this area of work:

Embedded configuration blocks yielding command-and-control hostnames, ports, campaign identifiers, sleep intervals and jitter values
Cryptographic constants, hardcoded keys and custom encoding routines that fingerprint a codebase across versions and forks
Import tables, API call sequences and syscall usage revealing capability: injection, credential theft, screen capture, lateral movement
Compilation artefacts such as build timestamps, PDB paths, toolchain markers, language identifiers and developer directory names
Code-signing certificates, whether stolen, fraudulently purchased or self-issued, linking samples to a shared acquisition channel
Anti-analysis behaviour: sandbox checks, debugger detection, geofencing and keyboard-layout checks revealing target and exclusion sets
Persistence and privilege-escalation mechanisms chosen, which map directly onto technique catalogues for detection engineering
Structural similarity to known families measured by function hashing, string overlap and control-flow graph comparison

Where the data comes from

Authoritative and openly available collection points. Always confirm licensing and terms before operational or commercial use:

VirusTotal — Multi-engine verdicts, file relationships, behavioural reports and retro-hunt across a very large sample corpus
MalwareBazaar (abuse.ch) — Free sample repository with family tagging, YARA matching and delivery context for each submission
ThreatFox and Feodo Tracker — Extracted command-and-control infrastructure tied to specific malware families and updated continuously
MITRE ATT&CK — Technique vocabulary for translating observed capability into concrete detection and coverage requirements
Hybrid Analysis and ANY.RUN — Free sandbox reports giving process trees, dropped files, registry changes and network captures
YARA and community rule sets — Signature language plus shared rules for classification, hunting and retrospective corpus searching
Ghidra — Free reverse-engineering suite for disassembly, decompilation, scripting and configuration extraction
Malpedia (Fraunhofer FKIE) — Curated family taxonomy, reference samples and reconciliation of conflicting vendor naming

A working method

A repeatable sequence beats ad-hoc searching. This is a practical starting workflow:

Acquire with provenance — Record where the sample came from, how it was delivered and its full hash set. Delivery context carries half the intelligence value.
Triage safely — Check existing knowledge by hash, identify file type and packing, and extract strings and metadata before executing anything at all.
Detonate in isolation — Run in an instrumented, network-controlled sandbox. Capture process trees, file and registry changes and full packet capture.
Unpack and extract — Dump the unpacked payload from memory, locate and decode the configuration block, and recover infrastructure and campaign fields.
Classify and link — Compare structure, strings and code against known families, recording both what supports the classification and what contradicts it.
Produce durable output — Write behavioural YARA and Sigma rules, publish extracted infrastructure, and map capability to techniques to expose coverage gaps.
Retro-hunt — Run new rules across historical sample archives and your own telemetry to surface earlier activity that went undetected.

How this connects across the intelligence taxonomy

Intelligence work does not respect neat boundaries. The mission domain you are working, the disciplines you practise, and the data points you pivot on are one connected system. These are the direct relationships for this entry — every link is also a tag, so you can follow any thread across the whole library.

Applied in these mission domains

Operates on these data points

Malware Family — A named class of related malicious software.
File Hash — Cryptographic fingerprint of a file, used for malware identification.
IP Address — Internet Protocol address identifying a device or server on a network.
Domain Name — Human-readable address that maps to IP infrastructure via DNS.
Detection Signature — A YARA/Sigma/Snort rule encoding detection logic for a malware family or behavior.
TLS / JA3 Fingerprint — A hash of TLS client-hello parameters used to fingerprint clients, malware, and C2 frameworks.
SSL/TLS Certificate — A digital certificate binding a public key to an identity.

Related disciplines

Attack Surface Intelligence — Your Own Exposed Attack Surface
Breach Intelligence — Exposed Credentials and Compromised Data
Certificate Intelligence — TLS Certificates and Certificate Transparency
Cyber Intelligence — Adversary Activity in Networks and Systems
Dark Web Intelligence — Hidden Services and Closed Criminal Venues
Domain Intelligence — Domains, DNS, and Registration Intelligence

Inside the platform: where Malware Intelligence lives

The Quantus platform is 204 pages behind a 147-item sidebar organised into six working groups: Command (24 items), Dashboards (15), Threat Theaters (14), Intelligence Domains (15), Investigate (34), and Administration (45). This entry is not a page in isolation — it is a thread running through several of them.

The modules that matter most here:

discipline.php?d=MALINT — Discipline hub
source-catalog.php?disc=MALINT — Source catalogue filtered to this discipline
hash-profile.php — Malware Family profile
ip-profile.php — IP Address profile
url-profile.php — Domain Name profile
search.php — Advanced search, filter and pivot
correlate.php — Correlation graph
cases.php — Case management

Each dashboard is local-first: it renders from the platform’s own database rather than depending on a live third-party call, so it still works when an upstream API is unreachable or rate-limited. Heavy aggregates are cached with a hard query time cap and degrade to the last good value instead of hanging the page.

Automation, playbooks and AI skills

Analysis that only happens when someone remembers to run it is not a capability. The platform ships a 30-step automation pipeline (cron.php) that collects, ingests, resolves, enriches, correlates and scores on a schedule — 25 seeders, 11 resolvers and 7 enrichment runners, all idempotent and cursor-based so a run can be interrupted and resumed without duplicating or losing work.

AI skills that apply

The 16 one-click operations in ai-skills.php are deterministic jobs, not free-text generation. The ones that matter here:

Correlate Infrastructure
DNS Audit
Threat Hunt
Detection Rules
Enrichment Runner
Summarise (Copilot)
Generate Report

Alerting closes the loop: rules in alerts.php fire on new indicators matching a saved query, so a first sighting in this area raises a notification rather than waiting to be noticed at the next review.

Feeds, data sources and the API

The collection layer runs a feed registry of free, machine-readable sources — bulk blocklists and trackers (Maltrail, IPsum, FireHOL, the full abuse.ch corpora, phishing databases, Emerging Threats, Spamhaus, DigitalSide, ThreatView), authoritative government feeds (CISA KEV, OFAC, UN and EU sanctions lists), and reference datasets (RIR allocations, ip-to-ASN and geolocation tables, MITRE ATT&CK, EPSS). collect.php pulls them server-side on a schedule; feeds.php and source-catalog.php show what is registered, what it covers and when it last ran.

Anything the platform holds is reachable programmatically. The REST API in api.php exposes 11 endpoints — status, stats, search, lookup, recent, export, bulk_check, top_threats, by_category, categories, check — and export.php streams 18 formats in bounded chunks, so a million-row export neither exhausts memory nor times out:

STIX 2.1, MISP, OpenIOC 1.1, CEF (ArcSight), LEEF 2.0 (QRadar), Zeek/Bro intel, Snort/Suricata rules, Palo Alto EDL, BIND RPZ, hosts blackhole, iptables, CSV, JSON, NDJSON/JSONL, XML.

That covers the CTI standards (STIX 2.1, MISP, OpenIOC), SIEM ingestion (CEF, LEEF, Zeek), detection engines (Snort/Suricata), and direct enforcement (Palo Alto EDL, BIND RPZ, hosts, iptables) — so intelligence developed here can be actioned in the tools you already run, without a manual reformatting step. A TAXII 2.1 server and a MISP/RSS feed are also served for pull-based sharing.

Use cases

Three ways this entry earns its keep in day-to-day work:

Triage under time pressure. An artifact or report lands and you need a defensible read in minutes, not days. Acquire with provenance is the first move; the platform pre-computes the enrichment so the analyst spends the time on judgement rather than lookups.
Building the picture. A single indicator is rarely the story. Detonate in isolation turns one artifact into a network — shared infrastructure, repeated selectors, the same operator behind different names — via the correlation graph and the cross-entity link engine.
Producing something actionable. Analysis that ends in a document nobody can use is wasted. Retro-hunt feeds the case file, the detection rule, the block list or the referral — with sourcing attached so the recipient can verify it.

Case management (cases.php), watchlists, saved searches and scheduled reports mean the work persists between sessions and survives an analyst leaving the team.

How each sector uses Malware Intelligence

The same entry is worked very differently depending on who you are, what authority you hold, and what you are ultimately producing. A military analyst is supporting a commander’s decision; a journalist is meeting a publication standard; an NGO caseworker is protecting a person. The underlying artifacts are shared — the constraints, outputs and thresholds are not.

🎖 Military and defence

Defence practitioners analyse malware to understand adversary capability and to defend mission systems. The work is conducted in accredited isolated laboratories, and the products are detection content, configuration extraction that reveals command infrastructure, and capability assessments that inform force protection and cyber terrain decisions. Analysis of samples recovered from mission networks supports incident scoping and attribution nominations through the formal process. Constraint: developing offensive capability from analysed samples is a separate function under separate authority, and the defensive analyst product stops at detection, characterisation and recommendation. Handling matters because a sample recovered from a defence network may itself reveal what the adversary achieved.

🕵 National intelligence

National services use malware analysis as a technical collection and characterisation discipline supporting attribution, capability assessment and warning. The distinctive contribution is depth: full reverse engineering to recover protocol detail, configuration and code lineage, fused with sensitive collection on the developers and operators. Code reuse and build artefacts support linkage between campaigns that infrastructure alone cannot establish. Products are structured so the technical findings, detections and indicators can be released to defenders and partners while the attribution and collection context is protected. Handling also reflects that publishing an analysis tells the developer exactly what to change, which is a real and recurring cost.

👮 Law enforcement

Investigators use malware analysis as forensic evidence. The sample recovered from a victim system is exhibited with continuity from seizure: hashed at acquisition, analysed on a copy, in a documented environment with recorded tooling versions. Analysis establishes what the code did on the victim system, what it collected, where it sent data and when, which supports both the offence and the loss. Code and infrastructure linkage supports joining separate incidents into one case. Development artefacts, language settings, build paths and account names occasionally provide identity leads, but these require corroboration through legal process rather than standing alone.

🔍 Private investigation and corporate security

Corporate practitioners analyse malware recovered from their own estate to scope incidents, extract indicators and build detections, usually at a triage and behavioural level rather than through full reverse engineering. Analysis must occur in isolated environments, and samples must never be submitted to public services without considering that submission is public: adversaries monitor for their own samples, and a victim-identifying sample uploaded publicly can reveal the intrusion. A private actor may not use analysed capability offensively, may not access the command infrastructure it identifies, and should route infrastructure findings to hosting providers and law enforcement rather than acting on them.

📰 Journalism and OSINT media

Journalists rely on malware analysis when reporting on spyware, sabotage and intrusion campaigns. Verification requires having the sample examined by an independent technical expert with the capability to reproduce the findings, and being precise about the difference between what the code does, where it connects and who wrote it, since these carry very different confidence. Do not publish sample hashes or code in a way that assists redistribution, and consider whether publication warns the operator before victims can be notified. Coordinate with the responders supporting victims, and give the named vendor or state a specific right of reply.

🌍 NGO, humanitarian and human rights

Civil society technical support organisations analyse malware and spyware recovered from the devices of activists, journalists and human rights defenders. Practice is consent-based and victim-centred: the device belongs to the person, examination requires informed consent and a clear explanation of what analysis will and will not reveal, and support must be in place before findings are delivered because a confirmed infection can indicate imminent physical danger. Documentation is prepared to accountability standards for litigation, export control action and United Nations mechanisms. Duty of care extends to analysts, who become targets of the same actors once the work is published.

🎓 University and research

Researchers study malware as a corpus: family evolution, packing and evasion prevalence, classifier robustness, and the effectiveness of detection approaches. Methodology must state the sample source, the labelling method and its error rate, and the time period, since evaluation on stale or mislabelled corpora produces results that do not transfer. Reproducibility requires publishing hashes and code rather than the binaries themselves. Ethics review is required, particularly for anything involving live infrastructure, sinkholing, or samples containing victim data, and institutional legal review should cover possession and distribution restrictions on malicious code in the relevant jurisdiction.

Playbook: working Malware Intelligence end to end

A repeatable sequence, from the moment the requirement lands to the moment a product is delivered and the case is closed out. Each phase states what you are trying to establish, not merely what to click — the point is a defensible chain of reasoning, not a checklist.

Phase 1 — Establish a safe analysis environment

Build isolated infrastructure before any sample is handled: dedicated hardware or hypervisor-isolated virtual machines, no route to corporate networks or identity, controlled or simulated internet access, snapshot and rollback, and a documented rebuild procedure. Assume every sample is capable of escaping careless containment and of detecting analysis. Record the environment configuration, because analysis results depend on it. A good output is a reproducible laboratory with a tested reset. Stop when a full compromise of the analysis environment would reach nothing else and the configuration is documented well enough to reproduce a result later.

Phase 2 — Acquire and preserve the sample

Capture the sample with continuity: record where it was found, on which host, at what path, at what time and by whom, and hash it immediately with a recognised algorithm. Work only on copies. Preserve associated artefacts, since a loader without its payload, a script without its arguments or a binary without its configuration file yields a partial and often misleading analysis. Note whether submission to public services is acceptable, because it is disclosure. A good output is an exhibited sample with continuity and context. Stop when the sample and its context are preserved and the disclosure decision is recorded.

Phase 3 — Triage before deep analysis

Establish quickly what you are dealing with: file type, size, entropy suggesting packing, embedded strings, imports, digital signature and its validity, compilation timestamps, and whether it matches a known family. Check internal prevalence across the estate, since a sample seen widely is a different problem from one seen once. Decide from this whether full reverse engineering is warranted at all, because most samples do not require it. A good output is a triage record with a family hypothesis and a decision on analysis depth. Stop when the analysis depth decision is justified.

Phase 4 — Static analysis

Examine the file without executing it: structure and sections, imports and exports, embedded resources, strings including those recovered after unpacking, cryptographic constants, embedded certificates, compiler and packer artefacts, and build paths. Static analysis is safe, is not defeated by sandbox evasion, and often yields the configuration and infrastructure that dynamic analysis would never trigger. Record everything with offsets so findings can be verified. A good output is a documented static profile with candidate indicators. Stop when the file structure and its embedded content are characterised or the sample requires unpacking first.

Phase 5 — Unpack and deobfuscate

Where the sample is packed, obfuscated or encrypted, recover the underlying code through the appropriate technique: memory dumping after execution in a controlled environment, emulation, or manual unpacking. Recover string decryption routines and apply them to obtain the real strings, which frequently contain command infrastructure, mutex names and campaign identifiers. Document the method so another analyst can reproduce it. A good output is the unpacked payload preserved alongside the original with the unpacking method recorded. Stop when the recovered code is complete enough to analyse rather than partially reconstructed.

Phase 6 — Dynamic analysis

Execute in the instrumented environment and record behaviour: process creation, injected code, file and registry activity, scheduled tasks and services, network connections and their protocols, and anti-analysis checks. Vary the environment to defeat conditional execution, since many samples check for domain membership, language settings, virtualisation or a specific date before behaving. Absence of behaviour is not absence of capability. A good output is a behavioural trace with the environment conditions recorded. Stop when the observed behaviour is stable across environment variations or the evasion condition is identified.

Phase 7 — Extract configuration

Recover the embedded configuration, which is the highest-value output of the whole process: command server addresses and fallbacks, campaign or affiliate identifiers, encryption keys, mutex names, target filters, sleep intervals and kill dates. Configuration extraction generalises across the family and can be automated to process new samples at scale, converting one analysis into ongoing infrastructure visibility. A good output is a structured configuration record plus a reusable extractor where the family warrants it. Stop when the configuration fields are recovered and validated against a second sample of the same family.

Phase 8 — Classify and establish lineage

Determine the family and its relationship to other code: shared functions, distinctive algorithm implementations, reused structures, identical error strings and common build artefacts. Compare against curated family references rather than trusting engine labels, which are inconsistent and often wrong. Distinguish genuine code lineage from shared use of a commodity builder or a public library, which produces convincing false relationships. A good output is a classification with the discriminating evidence and a confidence rating. Stop when the family assignment is evidenced rather than inferred from a scanner label.

Phase 9 — Produce detection content

Convert findings into defensive value: structural rules matching the code itself, behavioural rules matching what it does on a host, and network rules matching its protocol. Prefer signatures keyed to features expensive for the author to change, such as a custom protocol structure or a distinctive decryption routine, over ones keyed to a build artefact that changes on the next compile. Test for false positives against a clean corpus before release. A good output is validated detection content with a measured false positive rate. Stop when the rules fire on the family and not on benign software.

Phase 10 — Map to techniques and report

Map observed behaviour to a technique framework so it connects to detection coverage and actor profiling, and write the report for two audiences: responders who need indicators, behaviours and mitigation now, and analysts who need capability assessment and lineage. Include what the sample can do, what it did in this case, what remains unanalysed, and confidence per claim. A good output is a report that changes defensive posture within a day of issue. Stop when the responder actions are specific enough to execute without asking the analyst.

Phase 11 — Handle infrastructure findings lawfully

Command server addresses recovered from configuration are intelligence, not an invitation. Do not connect to, probe, or interact with adversary infrastructure beyond what your authority permits, and never attempt takeover or takedown yourself. Route findings to hosting providers, registrars, national CERTs, sharing communities and law enforcement, who can act lawfully. Where sinkholing is appropriate it is done by parties with the legal standing to do it. A good output is a notification with a reference and a tracked outcome. Stop when the finding is with a party who can act.

Phase 12 — Share and retain appropriately

Share analysis under a handling marking, considering that publication tells the developer what to change and that some findings are more valuable held within a trusted community for a period. Retain samples and analysis securely with access control, recognising that a malware repository is itself a risk and that some samples contain victim personal data. Record retention periods. A good output is a sharing decision that maximises defensive value against disclosure cost, with the reasoning recorded. Stop when the sharing decision is made deliberately rather than by default in either direction.

The platform ships this as a step-checked workflow in playbooks.php, so progress is recorded against a case rather than held in someone’s head.

Source register: what to collect from, and how

Sources are listed with their access model so you can plan around cost and licensing before you build a dependency on them. Open means no account required; registration means a free account or API key; licensed means paid or institutional access. Always confirm current terms — licensing changes, and a source that was free for research may not be free for commercial or evidential use.

Source	Access	What it gives you	How it is used here
MalwareBazaar	Open	Community malware sample repository maintained by abuse.ch with family tagging, hashes and submission context.	Acquisition of related samples for family comparison and validation of configuration extractors across builds.
Malpedia	Registration	Curated malware family library resolving naming synonyms with references to authoritative technical analyses and sample sets.	Authoritative family classification and synonym resolution, avoiding reliance on inconsistent scanner labels.
VirusTotal	Registration	Multi-engine analysis platform with behavioural reports, file relationships, submission metadata and retrohunting capability.	Prevalence, first-seen timelines and relationship pivoting, used with awareness that submission is disclosure.
ThreatFox	Open	Open indicator database associating indicators with malware families, with confidence scoring and community contribution.	Publishes and consumes family-linked command infrastructure derived from configuration extraction.
URLhaus	Open	Database of malware distribution URLs with payload references, hosting metadata and observation timestamps.	Identifies the distribution infrastructure delivering a family and supplies additional samples for comparison.
Feodo Tracker	Open	Tracking of botnet command and control servers for major loader and banking trojan families.	Validates extracted command server addresses against independently observed infrastructure for the same family.
SSL Blacklist	Open	Database of TLS certificates and JA3 fingerprints associated with malware command and control communication.	Supports network detection of family communication where payload content is encrypted.
YARA	Open	Pattern matching engine and rule language for classifying and hunting files by structural and content characteristics.	Encodes family classification and code-reuse findings into reusable rules for hunting and triage.
MITRE ATT&CK	Open	Adversary technique knowledge base with detection and mitigation guidance and references to primary reporting.	Maps observed sample behaviour to techniques so it connects to detection coverage and actor profiles.
Sigma	Open	Vendor-neutral detection rule format with community rules covering host and log-based adversary behaviour.	Encodes behavioural findings from dynamic analysis into portable host detection content.
MISP	Open	Open platform for structured storage, correlation and controlled sharing of samples, indicators and analysis objects.	Holds analysis output with provenance and handling markings and supports controlled community sharing.
Recorded Triage sandbox	Registration	Automated malware analysis service producing behavioural traces, family identification and configuration extraction at scale.	Rapid triage and automated configuration extraction before deciding whether deep analysis is warranted.
ANY.RUN	Registration	Interactive sandbox allowing analyst interaction during execution to trigger conditional behaviour.	Defeats samples requiring user interaction or specific conditions that automated sandboxes never trigger.
Ghidra	Open	Open source software reverse engineering suite with decompiler, scripting and collaborative analysis support.	Primary static reverse engineering environment for recovering algorithms, configuration structures and code lineage.

Prefer sources that publish a methodology and a revision history. A dataset that changes silently is a liability in any product that has to survive challenge.

Tooling

Tools commonly used against Malware Intelligence. None of these replace judgement, and each carries its own failure modes — know what a tool infers versus what it observes.

Ghidra — Full reverse engineering suite with decompiler and scripting for automation. Limitation: decompiler output requires interpretation and struggles with heavy obfuscation.
IDA Pro with Hex-Rays — Industry standard disassembler and decompiler with mature plugin ecosystem. Limitation: expensive licensing restricts access for smaller teams.
capa — Identifies capabilities in binaries by matching behavioural rules against disassembly. Limitation: rule coverage misses novel implementations and custom techniques.
YARA — Classification and retrohunting across sample corpora using structural rules. Limitation: rules keyed to packed or generated content break on the next build.
Sandbox platforms such as Triage and ANY.RUN — Produce behavioural traces and automated configuration extraction quickly. Limitation: evasive samples withhold behaviour, and submission is disclosure.
Binary diffing tools — Compare samples to establish code reuse and version lineage within a family. Limitation: shared libraries and commodity builders create convincing false relationships.
Memory forensics frameworks — Recover unpacked code and injected artefacts from memory images. Limitation: requires a capture at the right moment and knowledge of the target profile.
Network capture and protocol analysis tools — Record and interpret command and control traffic during dynamic analysis. Limitation: encrypted custom protocols require key recovery from the binary first.
Configuration extractor frameworks — Automate recovery of family configuration across many samples at scale. Limitation: break whenever the developer changes the configuration structure or encryption.

AI skills and automation in detail

These are deterministic jobs with defined inputs and outputs, not open-ended prompting. Each is idempotent and cursor-based: interrupt one and it resumes where it stopped rather than duplicating work or losing progress.

Correlate Infrastructure — Builds the cross-entity link graph: shared hosting, reused certificates, overlapping registrants, repeated selectors.
DNS Audit — Bulk-resolves A/AAAA/MX/NS/TXT/CNAME/SOA records and stores them as observations, building passive DNS from your own collection.
Threat Hunt — Runs saved hypotheses against the corpus and surfaces what matches, with the query preserved as a versioned artifact.
Detection Rules — Generates YARA, Sigma and Snort/Suricata logic from the selected indicators, ready to deploy.
Enrichment Runner — Walks the indicator set through a chosen provider in time-boxed, cursor-based batches that resume rather than restart.
Summarise (Copilot) — Produces a narrative summary beside the underlying records. It explains; it never creates indicators or assigns attribution.
Generate Report — Assembles a sourced product from the current case or query, with provenance attached to each element.

A note on the boundary: the only skill that involves a language model is Summarise (Copilot), and it writes prose about records that already exist. Nothing else on this list involves generation of any kind. No indicator, relationship or attribution in the platform originates from a model. See the full skill list.

Tradecraft notes

The distinctions that separate a competent analyst from a fast one:

Configuration extraction is the highest-value output, not the detection signature. One extractor converts every future sample of the family into current infrastructure visibility, which no static indicator list can achieve.
Absence of behaviour in a sandbox is not absence of capability. Samples check for domain membership, language settings, virtualisation, uptime and specific dates, so vary the environment before concluding that a sample does nothing.
Public submission is publication. Adversaries monitor sample repositories for their own tooling, and uploading a sample recovered from a victim network can disclose the intrusion and identify the victim from embedded paths and configuration.
Do not trust engine labels for family classification. Scanner names are inconsistent, frequently wrong and often generic, so classify against a curated family reference using discriminating code features and record what those were.
Distinguish code lineage from shared tooling. Commodity builders, public libraries and leaked source produce near-identical binaries from unrelated actors, and treating that similarity as attribution is a classic and consequential error.
Signature on what is expensive to change. A custom protocol structure or a distinctive decryption routine survives many builds; a compilation timestamp, a mutex name or a hardcoded path does not survive the next compile.
Preserve the whole artefact chain, not just the interesting binary. A payload without its loader, its script arguments and its configuration file yields an analysis that is partial and frequently misleading about what actually happened.
Command server addresses are intelligence, not an invitation. Connecting to adversary infrastructure exceeds most authorities, alerts the operator, and can constitute unauthorised access to a compromised third party host.

Measuring whether it is working

Capability claims should be falsifiable. These are the measures that show whether work on Malware Intelligence is producing anything, and they are worth baselining before you change process or tooling.

Median time from sample recovery to actionable detection content deployed in production, rather than to analysis report issued.
Proportion of analysed families for which a reusable configuration extractor exists and is still functioning against current samples.
False positive rate of released detection content measured against a clean corpus and against production alerting after deployment.
Share of family classifications supported by discriminating code evidence rather than by scanner labels, reviewed at quality assurance.
Number of command infrastructure findings routed to a party able to act, and the proportion resulting in a takedown or sinkhole.
Proportion of analyses reproducible by a second analyst from the preserved sample and documented environment.
Count of samples submitted to public services without a recorded disclosure decision, which should be zero.

Beware of measuring volume alone. Indicator counts and report counts rise easily and say little; time-to-attribution, proportion of findings that survive review, and how often a product changed a decision say a great deal.

Common pitfalls

Vendor family labels conflict and propagate, so treating an engine name as attribution silently imports someone else guesswork
Sandbox-aware samples behave benignly under analysis, meaning a clean dynamic report is never evidence of a clean file
Detonating without network control either blinds you to command and control or tells the operator you hold their sample
Static indicators taken from a packed sample describe the packer rather than the payload and produce worthless signatures
Uploading a targeted sample to a public multi-scanner discloses the intrusion to adversaries who monitor for their own tooling
Assuming code overlap proves shared authorship when the code is a public repository, cracked builder or purchased kit

Legal and ethical considerations

Possession and analysis of malware for legitimate defensive purposes is lawful in most jurisdictions, but several computer-misuse statutes criminalise supplying articles for use in offences, so distribution must be controlled and purposeful. Samples routinely contain victim personal data and stolen credentials, creating processing and minimisation obligations. Never execute a sample in a way that permits real-world harm such as outbound attacks, spam or botnet participation. Do not access adversary infrastructure beyond passive observation, and preserve original binaries with hashes where prosecution is possible.

Data integrity: no fabrication, no drift, no hallucination

Intelligence that cannot be traced back to a source is not intelligence, it is assertion. Everything in this entry — and everything in the platform behind it — is built on a small number of non-negotiable rules.

Provenance on every record

Every indicator carries the source that supplied it, a first-seen and last-seen timestamp, and a sighting count. Where several feeds report the same artifact, each contribution is recorded separately rather than collapsed, so you can see whether a finding rests on one source or twelve. Source attribution travels with the data into every export, so a recipient can audit a claim without asking you for the working.

Nothing is invented to fill a gap

If the platform has no data for Malware Intelligence, it says so. Empty is displayed as empty — never padded with plausible-looking placeholder values, sample records or illustrative examples that a reader might mistake for observations. A dashboard with no rows is a true statement about collection coverage, and it is treated as a gap to close, not a blemish to hide.

Scoring is deterministic and reproducible

Threat scores, reputation grades and risk tiers are computed from stated inputs with fixed weights, not estimated. The same inputs always produce the same output, and the formula is visible rather than a black box. Aggregates are cached with an explicit time-to-live so a figure on screen is never silently stale — and when a heavy query exceeds its time budget the platform serves the last known-good value and labels it, rather than inventing a fresh number or hanging.

Where AI is used, and where it is not

Language models summarise and explain. They do not create indicators, assign attribution or manufacture relationships. No IP address, wallet, hash or identity in the platform originates from a model — every one is ingested from a named feed, resolved from a reference dataset, or entered by an analyst with a source recorded. Copilot output is presented as narrative alongside the underlying records, never in place of them, so a reader can always check the summary against the evidence.

Guarding against drift

Enrichment is additive and timestamped rather than overwriting. Reference data — sanctions lists, allocations, taxonomies — is re-synchronised from the authority on a schedule instead of being edited in place, so local copies cannot quietly diverge from the source of truth. Attribution is recorded with a confidence level and the reporting it rests on, and inferred relationships are labelled as inferred. When a source retracts or corrects, the correction propagates rather than leaving a stale assertion behind.

What this means for you

You can put a finding from this platform in front of a regulator, a court, a board or a partner agency and show where each element came from. That is the standard the tooling is built to — because in this work, being confidently wrong is more damaging than being usefully uncertain.

By the numbers

The taxonomy this entry belongs to is not a marketing list — it is the actual structure of the platform: 52 mission domains, 52 intelligence disciplines and 65 data points, each with a live dashboard behind it. Supporting that: 18 indicator types, 14 playbooks, 16 AI skills, 18 export formats and a 30-step automated pipeline.

This particular entry connects directly to 7 data points, 3 mission domains, 6 closely related entries — every one of them a tag you can follow, and a dashboard you can open.

Questions analysts actually ask

Should I upload a sample to a public analysis service?

Only after a deliberate decision, because submission is publication. Adversaries monitor these services for their own tooling and will change infrastructure and rebuild once they see it, and samples frequently contain victim-identifying material such as internal paths, hostnames, campaign identifiers or targeted configuration. For targeted intrusions the default should be no, using private analysis and trusted community sharing instead. For commodity malware the disclosure cost is usually negligible and the enrichment benefit is real. Whichever you choose, record the decision and its reasoning in the case file, because it is frequently questioned later.

How much reverse engineering does an incident actually need?

Usually far less than analysts want to do. Most incidents need three things: what the sample did on the host, what it communicated with, and how to detect it elsewhere. Triage plus dynamic analysis plus configuration extraction delivers all three for the large majority of samples. Full reverse engineering is warranted when the family is novel, when the configuration or protocol cannot be recovered otherwise, when lineage matters for attribution, or when the evidential standard requires an authoritative account of the code behaviour. Decide explicitly and record the decision rather than defaulting to depth.

The sandbox showed nothing. What now?

Assume evasion rather than harmlessness. Vary the environment systematically: join a domain, change the system language and keyboard layout, add browser history and documents, extend uptime, adjust the system date, and use different processor and memory profiles. Try an interactive sandbox where an analyst can click through required interaction. In parallel, go static: unpack, recover strings and examine imports, since the checks themselves are visible in the code and identifying the trigger condition is often faster than satisfying it. Never report a sample as benign because a sandbox produced no behaviour.

How do I tell real code reuse from a shared builder?

Look at what the similarity actually is. Shared commodity builders, packers, public libraries and leaked source produce identical or near-identical code across completely unrelated actors, so overlap in those regions means nothing. Genuine lineage shows in custom implementations: a distinctive protocol structure, an unusual algorithm implementation, an idiosyncratic error handling pattern, or a bug carried forward between versions. Exclude library and builder regions before diffing, weight the remaining overlap by how unusual it is, and state the alternative explanation in the report. Do not build attribution on similarity in commodity components.

Is it lawful to connect to a command and control server?

For most organisations, no. Connecting to identified adversary infrastructure typically exceeds your authority, and that infrastructure is usually a compromised third party host, so interacting with it may constitute unauthorised access to an innocent victim system. It also alerts the operator and can destroy an investigation. Passive observation through scan data, passive DNS and certificate logs gives most of the same information lawfully. Where active engagement or sinkholing is genuinely warranted, it is done by parties with the legal standing and the coordination to do it, which means law enforcement or an established sinkhole operator.

How should malware samples be stored?

In a controlled repository with access restricted to named analysts, encrypted at rest, segregated from general infrastructure, and with a retention schedule. Treat the repository as a risk in its own right: it is an attractive target, an accidental execution hazard, and it may contain victim personal data extracted by the malware itself, which brings data protection obligations. Record provenance and continuity for every sample so evidential use remains possible. Review retention periodically and delete samples with no ongoing purpose, particularly where they contain personal data from victims.

When should analysis be published?

Weigh the defensive benefit against the disclosure cost deliberately. Publication distributes detection capability widely and is often the right answer for commodity threats affecting many organisations. It also tells the developer precisely what to change, and against a small number of targeted actors that cost is high and the retooling is fast. Intermediate options exist: share within a trusted community under a handling marking, delay publication until victims are notified and remediated, or publish behavioural detections without revealing the specific technique that produced them. Make the choice explicitly rather than by habit.

Standards, frameworks and further reading

Work that references a recognised framework is easier to defend, easier to hand over, and easier for a partner to consume:

MITRE ATT&CK, which governs the technique vocabulary used to describe observed sample behaviour and connect it to detection coverage.
ISO/IEC 27037 on digital evidence handling, which governs acquisition, hashing and continuity of samples intended for evidential use.
ISO/IEC 27035 on incident management, which governs the response process that analysis feeds and the reporting expected from it.
Traffic Light Protocol 2.0 published by FIRST, which governs handling and onward sharing of analysis and samples between organisations.
STIX 2.1 and TAXII 2.1, which govern structured representation and exchange of malware objects, indicators and relationships.
The UK Computer Misuse Act 1990 and equivalent legislation, which govern possession, supply and use of malicious code and interaction with third party systems.
ISO/IEC 29147 on vulnerability disclosure, which governs reporting of vulnerabilities discovered in the course of analysis.
The EU General Data Protection Regulation and the UK Data Protection Act 2018, which govern retention of victim personal data recovered inside samples.

References

Primary sources and authoritative references for this entry. Publishers revise and retire material, so treat the retrieval date as part of the citation and re-check before relying on any of it in a formal product.

MalwareBazaar sample repository — abuse.ch. Community malware sample corpus with family tagging and submission context
Malpedia malware family reference — Fraunhofer FKIE. Curated family library resolving naming synonyms with authoritative analyses
YARA pattern matching engine — VirusTotal. Rule language and engine for malware classification and hunting
Ghidra reverse engineering suite — National Security Agency. Open source disassembler and decompiler used for static analysis
ATT&CK knowledge base — MITRE. Technique reference for mapping observed malware behaviour
ThreatFox indicator database — abuse.ch. Family-linked indicator database fed by configuration extraction
SSL Blacklist and JA3 fingerprints — abuse.ch. Certificate and fingerprint data for detecting encrypted command traffic
Sigma detection rules — SigmaHQ. Portable behavioural detection content derived from dynamic analysis
Traffic Light Protocol 2.0 — FIRST. Handling markings governing sharing of analysis and samples
MISP threat intelligence platform — MISP Project. Structured storage and controlled sharing of malware analysis objects

Link integrity: every reference above was verified with a live request when this page was generated. Where a publisher had moved or withdrawn a document, the link was repointed at a preserved copy in the Internet Archive and marked as archived. Anything with no reachable copy anywhere had its link removed rather than left to rot — the source is still credited, it simply cannot be linked.

Put it into practice

The Quantus Intel threat intelligence platform operationalises this entry: automates triage, configuration extraction and retro-hunt across your sample archive and telemetry. Explore the platform, or browse the rest of the library by following any tag above.