On a Sunday morning the phone rings earlier than expected. There is an incident.
By the time you arrive, you still don't know whether you're dealing with a false alarm, an isolated piece of malware or the start of something a good deal more serious.
You start with the basics. The IDS and IPS alerts show anomalous activity. The WAF has logged suspicious requests. On the firewall a host appears with unusual outbound connections. The antivirus and the EDR point to unauthorised code execution. Everything suggests that one of the machines has been compromised, but you still don't know how, to what extent, or what the sample is actually capable of.
At that moment, the priority is not to put a neat label on the problem. The priority is to contain, understand and make sound decisions. While part of the team reviews immediate exposure, communications, credentials and possible spread, another line of work focuses on the sample: isolating it, observing it and working out what it actually does.
Because when malware turns up in a corporate environment, the question is not simply whether it is malicious. The real question is a different one: what it can do, what it has actually done and what you need to change right now so that the incident does not escalate.
That, in essence, is what malware analysis sets out to answer.
What malware analysis is
Malware analysis is the technical process by which a suspicious or malicious sample is studied in order to understand what it does, how it runs, what persistence it establishes, what communications it makes, what artefacts it leaves behind and what real impact it can have on an organisation.
It is not merely a matter of “running an antivirus” or uploading a file to an external service to see whether it flags. A real analysis seeks to answer operational questions:
- whether the sample steals credentials, tokens or cookies
- whether it establishes persistence
- whether it opens a backdoor
- whether it encrypts information
- whether it performs internal reconnaissance
- whether it attempts to move laterally
- whether it exfiltrates data
- whether it downloads further payloads
- whether it is designed to evade defensive controls
In other words, it is not just about classifying a sample, but about understanding its behaviour and translating it into decisions about containment, eradication, recovery and defensive improvement.
When malware analysis makes sense
Malware analysis makes sense when technical or contextual evidence appears that points to a genuine compromise or an attempted one. Some common scenarios are:
1. Alerts in EDR, antivirus, IDS, IPS or sandbox
When a tool detects a suspicious execution, a malicious file or anomalous behaviour, analysis helps to separate noise from real impact.
2. Incidents involving a possible endpoint or server compromise
If a machine has run an unknown sample or shown irregular behaviour, it is worth studying the sample to understand its scope and severity.
3. Phishing campaigns with malicious attachments or links
In email incidents, analysis makes it possible to confirm whether the attachment is a dropper, a loader, an infostealer, a RAT or a sample from another family.
4. Suspected data theft or exfiltration
If there are anomalous outbound connections or signs of improper access, analysis can reveal mechanisms for extraction, encryption, compression and evasion.
5. Post-incident validation
After initial containment, analysing the sample helps to confirm exactly what the malware did and which controls failed.
6. Regulated or auditable environments
In sectors where traceability, resilience and technical evidence particularly matter, malware analysis can form part of the technical support that follows an incident and of the justification for corrective measures. In those contexts it also pays to have well-developed capabilities in incident response and, where applicable, digital forensics.
What malware analysis sets out to achieve
Analysis done properly tends to pursue five main objectives.
Understand the actual functionality
What the sample does and what it appears to have been designed for.
Identify execution and persistence mechanisms
How it starts, what it touches on the system, whether it creates services, scheduled tasks, registry keys, DLL hijacking or equivalent mechanisms.
Detect communications and external dependencies
Which domains, IPs, URLs, C2 servers or services it talks to, and what protocol it uses.
Obtain useful indicators
Hashes, file names, mutexes, paths, keys, artefacts, domains, IPs, user-agents, patterns, YARA rules, IOCs and even IOAs.
Translate findings into defensive actions
What to block, what to review, which credentials to invalidate, which systems to isolate, which rules to improve and which controls to reinforce.
Types of malware analysis
Not every analysis has the same depth or the same purpose. The usual approach is to combine several of them.
1. Static analysis
Static analysis studies the sample without running it. It aims to extract structural and technical information from the binary, script, document or suspicious file.
It may include:
- hashes
- file type and actual format
- PE, ELF, Office or PDF headers
- imports and exports
- strings
- packers and obfuscation
- metadata
- embedded resources
- section names
- visible domains or paths
- obvious indicators of persistence or downloading
Advantages of static analysis
- it is fast
- it reduces risk by not running the sample
- it allows initial hypotheses to be formed
- it helps identify known families and packers
Limitations
- it does not always reveal the actual behaviour
- it can be very limited where there is packing, encryption or obfuscation
- many modern samples conceal precisely the most important part until run time
2. Dynamic analysis
Dynamic analysis observes the sample running under controlled conditions within an isolated environment. Its aim is to see the actual behaviour.
Here you review, for example:
- processes created
- injections
- changes to the registry or file system
- outbound connections
- DNS resolution
- creation of persistence
- interaction with system services
- second-stage downloads
- attempts to evade the sandbox or VM
- enumeration of the environment
- access to credentials, browser or email
Advantages of dynamic analysis
- it reveals actual behaviour
- it makes it possible to confirm hypotheses
- it gives operational context that is far more useful for containment
Limitations
- it requires a well-controlled environment
- some samples change their behaviour if they detect a lab
- a poorly contained execution can contaminate the environment
3. Hybrid analysis
In practice, the most useful approach is usually hybrid: static analysis first to profile the sample, then dynamic analysis to validate behaviour and obtain actionable evidence.
4. Manual analysis and reverse engineering
When the sample is significant, sophisticated or demands maximum precision, you move into deeper manual analysis:
- disassembly
- decompilation
- reversing of critical functions
- manual unpacking
- API tracing
- control-flow reconstruction
- analysis of encryption or obfuscation
- understanding of conditional and anti-analysis logic
This level is not always necessary, but it is what truly separates a superficial analysis from a useful one when complex samples have to be understood.
The technical methodology of a malware analysis
A serious analysis should not be improvised. It normally follows an orderly sequence.
1. Receiving and preserving the sample
The first step is to preserve integrity and context:
- the origin of the sample
- the affected system
- the time of detection
- the likely vector
- the user or service involved
- the tools that detected it
- associated evidence
At this stage it is advisable to maintain a technical chain of custody and not to handle the original without control, especially if the incident may escalate or requires more formal analysis later.
2. Initial classification
Before running anything, a basic identification is carried out:
- SHA256/MD5/SHA1 hash
- the real file type
- the observed name and extension
- possible links to known campaigns
- an initial risk assessment
3. Preliminary static analysis
This phase looks for quick clues:
- useful strings
- suspicious imports
- network artefacts
- persistence
- signs of packing
- the presence of scripts, macros, PowerShell, cmd or rundll32
- structures that point to a loader, dropper or stealer
4. Preparing the lab
The sample must not be run just anywhere. The lab must be isolated and controlled:
- snapshots
- segmentation
- process monitoring
- network monitoring
- memory capture where applicable
- change logging
- sufficient instrumentation
5. Controlled execution and observation
Here you observe what really matters:
- the process tree
- child and parent processes
- execution parameters
- files created or modified
- keys or tasks added
- privilege escalation attempts
- injection
- outbound communication
- host enumeration
- interaction with credentials or the browser
6. Extracting artefacts and indicators
Once the sample has been observed, IOCs and IOAs useful for defence are consolidated:
- hashes
- paths
- domains
- IPs
- mutexes
- keys
- user-agents
- persistence artefacts
- service names
- execution patterns
- detection or hunting rules
7. Operational interpretation
This is where analysis stops being academic and becomes useful. It is not enough to say “it's a trojan” or “it looks like a stealer”. You have to answer:
- what real risk it poses
- whether it could have stolen credentials
- whether it could have moved laterally
- whether it leaves persistent access
- whether it requires a credential reset
- whether it forces a review of email, identity, endpoints or the network
- whether it demands widening the search to other systems
The techniques commonly used in a malware analysis
On a technical level, analysis can draw on a range of techniques, depending on the sample and the context:
- hashing and fingerprinting
- extracting and reviewing strings
- analysis of headers and sections
- packer detection
- unpacking
- disassembly
- decompilation
- debugging
- sandboxing
- traffic capture
- memory analysis
- API tracing
- review of persistence
- hunting for artefacts on other machines
- generating YARA or equivalent rules
- correlation with ATT&CK and the observed TTPs
The key is not to confuse tools with methodology. Having reversing or sandbox utilities does not guarantee a good analysis if there is no technical judgement behind it.
What a malware analysis can uncover
A well-executed malware analysis can uncover considerably more than an initial alert usually reflects.
Theft of credentials or sessions
For example:
- the browser
- cookies
- saved credentials
- authentication tokens
- email credentials
- local technical credentials
Silent persistence
Such as:
- scheduled tasks
- services
- autorun keys
- DLL search order hijacking
- changes to shortcuts
- web shells or secondary droppers
Reconnaissance capabilities
The sample may enumerate:
- hostname
- domain
- users
- privileges
- processes
- defensive software
- drives
- the internal network
- active connections
Lateral movement or preparation
Some samples do not yet carry out lateral movement, but they do set the stage for it: stealing credentials, discovering the environment, enumerating shared resources or abusing built-in system tools.
Exfiltration
It may be possible to detect:
- prior compression
- encryption
- the use of HTTP/S, DNS or other channels
- data fragmentation
- C2 or intermediate storage
Evasion
Many samples try to detect:
- a VM
- a sandbox
- analysis tools
- a debugger
- typical process names
- artificial timing
- the absence of human interaction
The difference between malware analysis and digital forensics
Although they are related, they are not the same thing.
Malware analysis studies the sample to understand its behaviour and capabilities.
Digital forensics studies evidence from the system, memory, disk, logs and traces to reconstruct what actually happened during the incident.
In a serious case, the two disciplines complement each other. One tells you what the sample can do; the other helps you demonstrate what it has actually done in that specific environment.
The difference between malware analysis and incident response
These are not equivalent either.
Incident response covers containment, coordination, prioritisation, recovery and operational decision-making. Malware analysis is a technical capability that can be embedded within that response.
Put simply: analysis helps you understand; incident response helps you act.
Common mistakes in a malware analysis
There are several very common mistakes.
1. Analysing without context
The same sample does not carry the same risk in every environment.
2. Relying solely on automated detection
An antivirus signature or classification is no substitute for technical analysis.
3. Running the sample without sufficient isolation
This can worsen the incident or contaminate the analysis.
4. Stopping at the label
Saying “it's an infostealer” is of little use unless you pin down what it steals, how it persists and what to review.
5. Not translating findings into actions
Analysis must end in measures: blocking, hunting, hardening, credential rotation, rule improvement and exposure validation.
How it relates to pentesting, hardening and vulnerability management
Although these are distinct disciplines, there is a clear connection.
A malware analysis can reveal flaws or weaknesses that should be corrected through:
- system hardening
- execution control
- segmentation
- identity review
- privilege reduction
- email protection
- improved monitoring
- reinforcing vulnerability management
In the same way, an organisation that already has maturity in technical validation, such as audits or penetration testing, tends to be better prepared to interpret the real impact and to close off the attack paths a sample has exploited or tried to exploit.
Does it make sense for a mid-sized company or only for large organisations
It also makes sense for SMEs and mid-sized companies, especially when they depend on:
- Microsoft 365
- remote access
- cloud services
- ERP systems
- shared files
- IT providers
- privileged credentials
- sensitive operational continuity
You don't have to be a large organisation to be hit by loaders, stealers, ransomware, advanced phishing or identity abuse. In fact, many campaigns are designed precisely for environments with less defensive maturity.
The sectors where it can be especially relevant
Malware analysis becomes even more valuable in:
- financial environments or those subject to operational resilience requirements
- organisations with regulatory requirements
- industry and logistics
- healthcare
- B2B SaaS
- companies heavily dependent on Microsoft 365
- companies with sensitive data or business-critical continuity
In these cases, it matters not only to contain the incident but also to justify, on technical grounds, its scope, the response and the corrective measures.
What a malware analysis report should include
A good report should not settle for a vague description. It should include:
- a clear executive summary
- the context of the incident
- identification of the sample
- the methodology used
- the behaviour observed
- the persistence detected
- the communications observed
- technical indicators
- the potential impact
- the observed impact, where it can be determined
- the level of criticality
- the limitations of the analysis
- recommendations for containment and improvement
- additional hunting or validation actions
In summary
Malware analysis is neither a decorative exercise nor a laboratory curiosity. It is a critical technical capability when an organisation needs to understand what got in, what it did and what real risk remains open.
In a serious incident, deleting a file does not solve the problem. What matters is knowing whether there was credential theft, persistence, lateral movement, a second-stage download, exfiltration or preparation for a bigger impact. And that calls for technical analysis with method, judgement and operational context.
That is why, when a malicious sample turns up in a corporate environment, the right question is not just “which malware is this”. The right question is: what it is capable of, what trail it leaves and what you must do now so that the incident does not go any further.
Need to analyse a suspicious sample or review the scope of an incident?
If an organisation needs to analyse a suspicious sample within a real incident, the sensible thing is to tackle it as part of an orderly strategy of containment, investigation and improvement, combining capabilities in incident response and digital forensics.