Overview
Analysis runs in three passes. Static review of the file structure, strings, imports and embedded resources establishes what it could do. Dynamic execution in an isolated sandbox records what it does: files touched, registry and persistence changes, processes spawned, network destinations contacted. Manual reverse engineering then resolves whatever the sample deliberately hid: packing, anti-analysis checks, encrypted configuration, and logic that only triggers under specific conditions.
The deliverable is built to be actionable rather than academic. Indicators of compromise, YARA rules and detection logic come with the report, so the same sample and its variants can be hunted across the rest of the estate immediately.
Engagement at a glance
- Turnaround
- Triage within 24 hours; full report in 3 to 5 working days
- Sample types
- Windows and Linux binaries, scripts, macro documents, mobile packages, firmware
- Analysis
- Static, dynamic and manual reverse engineering in an isolated lab
- Deliverable
- Capability report, IOCs, YARA rules and detection guidance
- Handling
- Isolated environment, no sample sharing without written consent
- Escalation
- Findings feed straight into incident response where needed
What is covered
Every item below is tested and recorded, so the report shows what held as clearly as what failed.
- File triage and classification
- Static analysis: structure, strings, imports, resources
- Unpacking and deobfuscation
- Dynamic execution in an isolated sandbox
- Manual disassembly and decompilation
- Anti-analysis and sandbox-evasion identification
- Configuration and C2 extraction
- Persistence mechanism identification
- Network indicator extraction
- YARA rule authoring
- MITRE ATT&CK technique mapping
- Attribution context where evidence supports it
Test matrix
What is attempted in each class, and what it means when it works.
| Class | What is attempted | Typical impact |
|---|---|---|
| Capability | What the sample can do: collection, encryption, credential theft, lateral movement, remote control | The realistic worst case for a machine that ran it |
| Persistence | How it survives reboot and standard remediation | Whether cleaning the machine is sufficient |
| Command and control | Extracted configuration, domains, addresses, protocols, encryption keys | Blockable indicators and evidence of live operator control |
| Evasion | Sandbox detection, debugger checks, delayed execution, environment keying | Why your existing controls did not flag it |
| Data handling | What it collects, stages and transmits | Scope of the data exposure to report |
| Family and variant | Code and configuration overlap with known families | Context on the adversary and their likely next step |
What we commonly find
A loader, not the payload
The submitted sample is frequently only the first stage. The interesting capability arrives later, which means the incident is bigger than the file that was found.
Environment-keyed execution
Samples that only decrypt their payload on a machine matching a specific domain or user, so a sandbox verdict of “benign” is wrong.
Legitimate tooling in the chain
Signed remote administration tools used as the actual implant, which is why endpoint controls stayed quiet.
Indicators already present elsewhere
The extracted C2 indicators, hunted across the wider estate, routinely surface machines nobody had flagged.
How the engagement runs
Scoping and threat modelling
Map the asset, the attacker profile, and what “compromised” actually means for this business. Rules of engagement, testing windows, excluded techniques and an escalation contact are agreed in writing before anything is sent.
Reconnaissance and surface mapping
Enumerate everything reachable: subdomains from multiple passive sources, every endpoint referenced in JavaScript bundles, exposed services, third-party integrations, and the assets nobody remembers deploying. Coverage is recorded per host, so what was not tested is as visible as what was.
Manual exploitation
Authenticated testing from every role, with at least two accounts per role. Business logic, authorisation boundaries, injection, race conditions and state transitions, with each candidate reproduced live before it is written down. Automated tooling contributes coverage; it never contributes findings.
Verification and impact
Every finding is reproduced in a fresh session, isolated to the single parameter that causes it, and pushed to its maximum realistic impact. A finding that cannot survive a clean-room reproduction does not appear in the report.
Reporting and retest
The report is written twice over: once for the engineer who has to fix it, once for the auditor who has to file it. A walkthrough session follows, then a retest of every finding, closed only when re-exploitation fails.
What you receive
Executive summary
One page for the people who approve budget: what was tested, what was found, what it means in business terms.
Technical findings
Each finding with severity, CVSS, affected component, full request and response, reproduction steps and a working proof of concept.
Attack chains
Where findings combine, the chain is written out end to end, from first request to demonstrated impact.
Remediation guidance
A specific fix for your stack and framework, with the corrected pattern, not a link to a generic reference page.
Audit mapping
Findings mapped to SOC 2, ISO 27001, PCI DSS, HIPAA and OWASP ASVS as applicable, so the report drops straight into an audit pack.
Retest and attestation
Every finding retested in a clean session after remediation, with a signed attestation letter for customers and auditors.
When to run it
- Immediately when a suspicious file is recovered during an incident.
- When endpoint tooling flags something it cannot classify.
- After a phishing campaign, to understand what the attachment did.
- When you need YARA and detection content for a threat specific to your sector.
Questions
How quickly can you analyse a sample?
Initial triage within 24 hours of receipt: malicious or not, what family, what immediate indicators. A full capability report with YARA rules and detection guidance follows in three to five working days, faster where an active incident is running.
How do you handle our sample?
In an isolated analysis environment with no path back to your network or ours. Samples are never uploaded to public multi-scanner services without your written consent, because that publishes the fact of your incident to anyone watching those feeds. Samples are destroyed at engagement closure unless you ask us to retain them.
Can you tell us who sent it?
Sometimes, and only where the evidence supports it: code overlap, infrastructure reuse, tooling patterns. Attribution is reported with an explicit confidence level, and we say “unknown” when that is the honest answer. Confident attribution from a single sample is usually a marketing claim rather than an analytical one.
What do we get that we can actually use?
Indicators of compromise, YARA rules, network detection guidance and a remediation checklist covering persistence the sample established. All of it is written to be deployed the same day, not filed.
How much does malware analysis cost?
Pricing follows sample count and depth: triage is fast and cheap, full reverse engineering of a packed, obfuscated sample is neither. A fixed quote follows a short call, and during an active incident triage starts before the paperwork closes.
What is the difference between static and dynamic analysis?
Static analysis reads the sample without running it, which is safe and shows capability the sample may never exercise. Dynamic analysis detonates it in an isolated environment and records what it does. Packed and evasive samples need both, because each one hides what the other sees.
Can you analyse ransomware and tell us if decryption is possible?
We can identify the family, extract indicators, and determine whether the implementation has a known flaw or a public decryptor. Most modern families do not. We will tell you plainly when recovery through decryption is not realistic rather than leaving you hoping.
Do you produce YARA rules?
Yes, written against stable characteristics rather than against a single sample's hash, so they survive recompilation. Rules are delivered with the report along with network detection guidance and the indicators that support hunting across the rest of your estate.
Can you analyse a suspicious document or email attachment?
Yes, and it is one of the most common requests. Macro and script-bearing documents, malicious PDFs and archive droppers are analysed for what they fetch, what they execute and what they leave behind, which is usually the question that matters after a phishing campaign.