WannaCry Malware Analysis

Analysis snapshot

Authorised scope

Individual CMP320 analysis of a supplied WannaCry sample inside disposable, isolated Windows and analysis environments.

My contribution

I performed PE and resource inspection, followed selected code in Ghidra, observed execution, captured and analysed memory, reviewed packet traffic, and correlated the findings into detection and response opportunities.

Technical focus

• Static PE analysis
• Ghidra decompilation
• Isolated dynamic analysis
• Volatility memory forensics
• Process and registry behaviour
• Network traffic correlation

Demonstrated outcome

The combined file, code, host, memory and network evidence confirmed the WannaCry classification and execution chain. The project did not reverse the full encryption algorithm, analyse EternalBlue propagation or recover keys.

Investigation overview

This project was my CMP320 / Advanced Ethical Hacking malware-analysis investigation. I was given a suspicious Windows executable and asked to establish whether it was malicious, identify what it did, document its effect on the system, and produce evidence that could support detection and incident response.

I analysed the sample through four connected views: Portable Executable inspection, Ghidra decompilation, execution inside a disposable Windows virtual machine, and post-execution memory and network analysis. The point was not only to identify the family. A VirusTotal result already associated the file with WannaCry. The useful work was explaining how the outer executable prepared its environment, which behaviours could be supported from the code, which components appeared during execution, and how the host, memory and traffic evidence agreed.

Static analysis showed misleading DiskPart metadata, imported resource and registry APIs, embedded utilities, an encrypted archive and a hard-coded archive password. Following the code in Ghidra identified routines for retaining a working path, extracting resources, selecting payment-address state, launching supporting commands and resolving additional Windows APIs before the encryption stage.

During isolated execution, the launcher created two WannaDecryptor processes, unpacked supporting files, generated sustained disk activity, changed the desktop and displayed the ransomware interface. A memory capture then preserved the parent-child process relationships, access to a key-related file, registry handles, command-line state and a local connection associated with one active process.

The packet capture showed repeated encrypted outbound attempts to infrastructure associated at the time with Tor relays and hosting providers. Some connections completed TLS negotiation, some were reset and others received no response. I treated those addresses as historical context rather than durable indicators. The stronger detection opportunity was the combined sequence: an untrusted executable carrying embedded resources, writing persistence and support files, launching decryptor components, changing recovery-related state and initiating unusual encrypted communications.

The result was a confirmed WannaCry ransomware classification supported by evidence from the file, decompiled code, live system, memory image and network capture. The project did not reverse the complete encryption algorithm, analyse propagation through EternalBlue, or recover decryption keys. Those limits are stated directly rather than implied away.

Analysing a supplied WannaCry sample

I completed this investigation for CMP320 / Advanced Ethical Hacking in 2022/23. The task was to analyse a supplied suspicious Windows executable, determine whether it was malicious, identify its purpose and behaviour, and produce indicators that could support detection and incident response.

I treated the sample as untrusted throughout. Analysis took place in an isolated virtual machine with separate working copies and no connection to production systems. The public page documents the investigative method and findings, not the sample itself.

I set five questions for the investigation:

1. Was the supplied program malicious?
2. What function or malware family did it belong to?
3. How did it prepare and execute its main behaviour?
4. What impact did it have on the Windows system?
5. Which file, host, process, memory, and network observations could support detection?

The work used three complementary views:

• static analysis to inspect the executable without running it
• dynamic and memory analysis to observe what changed during execution
• network analysis to examine the traffic produced by the infected system

Each view answered different questions. Static analysis exposed structure and likely capability. Dynamic analysis showed which paths actually executed. Memory and network evidence then provided context that was not visible in the file on disk.

Scope and lab controls

The supplied binary was already a known historical sample, but I still treated it as live malware. The analysis environment was kept separate from personal and production systems. I used a disposable Windows guest for execution and separate analysis environments for memory and packet review.

The practical controls were:

• keep the original sample outside normal working directories;
• use a dedicated virtual machine and snapshots;
• prevent access to production networks and shared personal files;
• capture evidence before reverting the guest;
• transfer the memory image and packet capture into separate analysis systems;
• avoid testing encryption against real data;
• document the sample rather than publishing it.

The project used third-party services such as VirusTotal and Intezer because the sample was already a recognised teaching artefact. In an investigation involving an unknown internal file, uploading it to an external service could disclose sensitive code or data and would need explicit approval.

I separated the evidence into four levels:

Evidence level	What it could establish
File structure	What the executable contained and appeared capable of doing
Decompiled code	How selected functions and call sites were connected
Live execution	Which processes, files and visible changes occurred in the lab
Memory and traffic	Which runtime relationships, handles, arguments and connections remained observable

This mattered because capability and execution are not the same claim. An imported API can form a useful hypothesis without proving that the path ran. A sandbox label can guide investigation without replacing local evidence. A process or packet can prove activity at a point in time without explaining the complete implementation.

Analysis plan

I used the initial static findings to decide what to watch during execution rather than running three disconnected exercises.

Stage	Questions	Evidence and tools
File identification	Was the sample already classified, and did its metadata agree with that identity?	VirusTotal history, hashes, PE metadata
PE inspection	What sections, resources, strings, and imports suggested capability?	CFF Explorer, PE-Bear, Cerbero Suite, string extraction
Decompilation	How did the launcher move from its entry point into resource extraction, persistence, and encryption setup?	Ghidra call flow, renamed functions, cross-references
Live execution	Which processes and files actually appeared, and what visible impact occurred?	Disposable VMware guest, Process Hacker, before-and-after observations
Memory capture	Which process relationships, handles, arguments, and connections survived in RAM?	FTK Imager and Volatility
Network capture	Which destinations were contacted, on which ports, and how did each connection end?	Wireshark, TCP stream review, historical DNS and service context

This gave me a correlation chain from code to observed behaviour. For example, resource APIs in the import table led to the embedded-resource routines in Ghidra, then to dropped files during execution. Registry APIs led to a persistence function, then to registry handles in memory. Tor-related sandbox observations led to selected packet streams, but I still checked the local capture before accepting the sandbox interpretation.

I used that correlation model throughout the analysis:

static clue
    -> decompiled implementation
        -> runtime behaviour
            -> memory or network residue
                -> detection opportunity

Not every chain reached every stage. The static analysis identified capability that could not always be observed during one execution window. Memory contained only the state present when it was captured. Network traffic showed connection attempts but not the encrypted application data. The conclusion came from agreement between the stages rather than demanding that one tool explain the whole sample.

I also recorded uncertainty in the function names. Ghidra generated labels such as FUN_00401fe7; names including ExtractResources and BitcoinAddress were labels I assigned to make the analysis readable. They described supported behaviour and were not presented as recovered original source names.

Static triage and executable structure

The first pass established file identity and structure. A historical VirusTotal check returned 67 positive identifications and classified the sample as WannaCry. That result answered the initial classification question, but it did not replace analysis of the binary.

CFF Explorer, PE-Bear, and Cerbero Suite were used to inspect Portable Executable metadata, sections, resources, and imported functions. The metadata presented the program as diskpart.exe, although its structure and behaviour did not match the legitimate Windows disk-management utility. The executable appeared to have been compiled with Microsoft Visual C++ 6.0 and carried additional resources inside the binary.

The metadata mismatch was an investigative lead rather than a classification on its own. Legitimate and malicious software can both contain inaccurate timestamps, old compiler signatures or copied version resources. In this case, the identity became meaningful when it was combined with the resource section, registry functions, supporting files and ransomware behaviour.

The PE inspection also helped define what to observe during execution. Resource APIs suggested that the file would unpack additional material. Registry APIs suggested retained state or persistence. CopyFile, module-path functions and process creation suggested that paths and child components would matter. LoadLibraryA and GetProcAddress meant the static import table would not contain every function used later.

The import table included Windows functions associated with:

• locating and loading embedded resources
• allocating and changing memory protections
• copying and querying files
• reading and writing registry keys
• loading libraries and resolving function addresses
• using Windows cryptographic services

An imported API is not evidence of malware by itself. The combination of resource extraction, registry modification, memory-management functions, file operations, and misleading metadata provided a stronger basis for investigation.

The imports supplied useful hypotheses:

API group	Examples observed	Investigative question
Resource handling	FindResourceA, LoadResource, LockResource	Was the executable carrying secondary files or configuration inside its resource section?
Memory handling	VirtualAlloc, VirtualProtect	Did the program prepare or transform material in memory before use?
File and module handling	CopyFile, GetModuleFileName, GetModuleHandle	Did it copy itself or supporting files and derive paths relative to the running module?
Registry handling	RegCreateKey, RegSetValueEx, RegQueryValueEx, RegCloseKey	Did it save state or establish persistence through the registry?
Dynamic resolution	LoadLibraryA, GetProcAddress	Were additional functions selected only at runtime?
Cryptographic context	CryptReleaseContext	Did later code use Windows cryptographic services?

Import analysis was useful because it narrowed the search without requiring me to understand every function immediately. It was not a signature by itself. Many legitimate installers also load resources, create registry values and launch processes. The stronger interpretation came from the way these groups appeared together and the specific strings, resources and runtime behaviour connected to them.

Following the code in Ghidra

I loaded the binary into Ghidra and worked outwards from the entry point. The decompiler’s generated function names were replaced with descriptive labels as their purpose became clearer. This made it easier to follow the call flow without pretending that every branch had been fully recovered.

The main routine established local state, located its working directory, checked command-line arguments, and called into the functions responsible for copying files, extracting resources, and starting the encryption workflow.

The resource section contained supporting components, including compression utilities and an encrypted archive. String analysis exposed a hard-coded archive password, which helped explain how the bundled files were unpacked at runtime. The sample was therefore not one self-contained routine; it acted as a launcher and resource carrier for several parts of the ransomware.

The embedded strings identified inflate 1.1.3 and unzip 0.15. The archive password WNcry@2017 was passed into the routine I labelled DecryptZipFile. Those details linked the resource section to a concrete unpacking mechanism rather than leaving the embedded data unexplained.

This explained why the on-disk executable and the post-execution directory looked so different. The outer file acted as a carrier. It did not need every operational component to appear as a normal standalone import or neighbouring file before execution.

That design also created several detection surfaces:

• a PE resource section containing executable or archive material;
• strings belonging to bundled extraction tools;
• an archive opened with a command-line password;
• child processes or files appearing shortly after the launcher starts;
• permissions changed recursively on a newly created working directory.

None is unique to WannaCry in isolation. Their timing and relationship to an untrusted executable make them more useful.

Main routine and execution setup

The entry path set up exception handling and local variables, located the current working directory, examined command-line arguments, and called a function originally labelled FUN_00401fe7. That path led into file copying, embedded-resource extraction, and preparation of the encryption process.

I worked from references and call sites rather than reading the decompiler from top to bottom. For each candidate routine I checked:

• the parameters passed into it;
• the Windows APIs it called;
• strings and globals referenced by the function;
• the value it returned;
• where the return value was tested;
• which later observation could support the interpretation.

That approach reduced the risk of naming a function from one interesting string while ignoring how the caller used it. It also exposed places where my original labels were narrower than the implementation. DecryptZipFile, for example, was a general process-launching wrapper used with different command lines rather than a dedicated archive algorithm.

I renamed functions according to the behaviour I could support from their control flow. The labels were analytical aids, not recovered source-level names:

• ExtractResources described the resource lookup, loading, locking, extraction, and cleanup path
• BitcoinAddress described selection and persistence of one value from three embedded addresses
• DecryptZipFile described process creation around the bundled extraction and permission-changing commands
• EncryptionProcess described the function-pointer preparation immediately before the encryption stage

This naming made the call graph readable while preserving uncertainty about details that were not completely recovered.

Persistence and file placement

The function originally labelled FUN_004010fd accepted one integer argument and selected either the machine or current-user registry context. In one branch it retrieved a stored path and set the process working directory from that value. In the other it obtained the current directory and wrote it back to the registry. It returned success only when the key and value operation completed.

The same path copied tasksche.exe into the working directory and queried its file attributes. The registry value therefore provided retained location state, while the copied executable formed part of the later execution and persistence behaviour.

The static analysis also identified:

• resource lookup through FindResourceA
• loading and locking resource data in memory
• extraction of embedded files to disk
• changes to file permissions
• selection from several embedded payment addresses
• runtime resolution of selected Windows functions

The runtime lookup pattern reduced reliance on a completely explicit static import table. It did not make the behaviour invisible, but it shifted part of the analysis from file structure to execution telemetry.

Extracting embedded components

The ExtractResources routine took a module handle and attempted to locate a specific embedded resource. When found, it loaded and locked the resource, passed its address and size into a subordinate extraction function, and checked the resulting data for an expected string. It then used file attributes to decide whether the component already existed before writing it to disk, followed by cleanup of the allocated material.

That sequence explained several later observations:

locate resource
    -> load and lock bytes
    -> pass bytes and size to extraction code
    -> inspect expected output
    -> check whether the target file exists
    -> write missing component
    -> free temporary material

It also separated unpacking from file encryption. The launcher first assembled the tools and resources it needed; the ransomware activity followed from that prepared working set.

Payment-address state

The function I labelled BitcoinAddress contained three embedded address strings and called a separate file-input/output routine. If no retained value was available, it generated a number, selected an address using the remainder after division by three, copied the selected value into a buffer, and persisted it.

The supporting file routine changed behaviour according to its second parameter: one branch opened the state file for writing, while the other read existing data back into the supplied buffer. This showed how the displayed payment state could be selected once and then reused rather than chosen independently at every invocation.

Process creation and file permissions

DecryptZipFile prepared process and startup structures, launched a command through CreateProcessA, optionally waited for completion, collected an exit code, and closed the process and thread handles. I observed two call sites around the setup path. One invoked the bundled extraction command; the other changed permissions recursively on the prepared working files.

My label reflected how the function was used in that path, but the routine itself was a more general process-launching wrapper. Distinguishing the wrapper from its call-site arguments prevented the implementation from being described too narrowly.

Immediately before the encryption stage, another function loaded kernel32.dll, resolved several APIs through GetProcAddress, stored the resulting pointers in global variables, and checked that every required address had been populated. Static imports therefore described only part of the execution surface.

Encryption workflow

The decompiled code showed a sequence that prepared bundled resources, unpacked supporting components, and then entered the file-processing stage. I focused on how the program assembled its working environment rather than attempting to reproduce the ransomware’s encryption against real data.

The archive password, embedded tools, registry changes, and resource-extraction routines showed how the sample carried what it needed inside the executable. This helped distinguish the outer launcher from the files and processes that appeared after execution.

Dynamic analysis in an isolated Windows VM

I executed the sample in a disposable Windows virtual machine and recorded the machine before and after detonation. Process Hacker was used to watch process creation, resource use, and visible file-system changes.

I began from a snapshot so the guest could be reverted after evidence collection. The execution window was intentionally limited. I watched the process tree, disk activity, working directory and desktop rather than interacting with personal or networked files.

The live stage had three purposes:

1. confirm that the static preparation path was used;
2. identify the processes and files created by the launcher;
3. decide when to capture memory and stop the experiment.

The executable launched under the misleading DiskPart identity and generated two WannaDecryptor processes. The system then showed the familiar ransomware interface and a changed desktop background. Files and supporting executables appeared in the working directory as the embedded resources were unpacked.

The before-and-after comparison provided several distinct forms of evidence:

• the original executable remained visible under the DiskPart-style identity
• two WannaDecryptor processes appeared beneath the execution chain
• sustained disk input/output accompanied the file changes
• the desktop background and GUI changed
• ransomware support files, key-related files, and encrypted extensions appeared
• the process tree tied the visual result back to the original launcher

The process tree gave the first clear runtime relationship between the initial launcher and the decryptor components. Visual changes confirmed impact, but the process and file evidence was more useful for explaining how that impact was produced.

I also compared the observed behaviour with a historical Intezer sandbox result. The sandbox mapped activity to techniques including:

• modifying the ransom message and desktop
• creating startup persistence
• deleting or attempting to delete volume shadow copies
• dropping supporting files
• preparing Tor-related communication

Sandbox output was treated as another source to verify, not as an unquestioned answer. I checked the file changes and network observations independently where the local lab evidence allowed it.

The local and sandboxed executions did not provide identical visibility. The sandbox could identify a wider range of behaviours from its instrumentation and prior knowledge. The local VM gave me direct control over timing, memory acquisition and packet capture. I used the sandbox to prioritise checks, then separated what I had personally verified from what remained an external observation.

The visible ransomware screen was the clearest demonstration of impact but not the strongest detection evidence. A user interface can be changed or removed. The more durable sequence was the launcher creating related processes, writing support files, changing permissions and persistence state, and generating widespread file activity.

Capturing and examining memory

FTK Imager captured the VM’s memory after execution. I transferred the capture to a separate analysis environment and examined it with Volatility.

Process-list and process-tree analysis showed the original executable and the two WannaDecryptor instances. Handle inspection exposed access to registry keys and files associated with the ransomware’s encryption state. Command-line analysis showed that most components ran without extensive arguments, while one decryptor instance received a short mode argument.

Memory analysis gave me a different type of proof from a directory listing. A file on disk showed that an artefact existed. An open handle showed that a process had it open at the acquisition point. A command line recorded how a process had been started. The process tree linked components that could otherwise be mistaken for unrelated executables.

I recorded the co argument as an observed value rather than assigning a purpose I could not prove. Similarly, the local connection associated with one process showed communication state without by itself identifying the meaning of the protocol.

A stronger future acquisition would include several memory captures at controlled stages: immediately after launch, during active file processing, after the ransom interface appeared and after network communication began. That would make it easier to distinguish short-lived setup processes from persistent components and to recover transient decrypted configuration.

Handle output included access to the 0000000.ekey file and relevant registry state. Command-line output showed the short co argument on one decryptor process. Network-state analysis found a localhost connection associated with process ID 2308. The memory capture therefore connected process identity, open handles, command-line state, and network activity at a particular point in execution.

I used several Volatility views together:

View	Evidence recovered
Process list	The initial process and two WannaDecryptor instances
Process tree	Parent and child relationships between the active components
Handle inspection	Registry and key-related file access, including 0000000.ekey
Command lines	Mostly argument-free execution plus the co mode argument
Network state	A local connection associated with one active process

This stage was especially valuable because disk inspection could not show every runtime relationship. Memory preserved:

• processes that had been created
• parent and child relationships
• open files and registry handles
• command-line arguments
• active or recently active network state

The capture was only a snapshot. Activity that completed before acquisition or started afterwards would not necessarily be present, so I compared it with the live monitoring and packet capture rather than treating it as a complete record.

Network traffic and Tor-related connections

Wireshark captured traffic from the test VM during execution. I used the sandbox observations to identify connections worth reviewing, then followed the corresponding TCP streams and TLS handshakes in the local packet capture.

I captured a 291,604-byte wcry.pcapng with SHA-256 cab2a072f2cbf407a35c8a44871c0e4daea5de042cc694a03b6c28c88a25b174. Static packet parsing recovered 545 records, including the repeated SYN and reset sequence involving 128.31.0.39 and multiple outbound port-443 flows from the test guest. I reviewed five historical destinations individually below.

Five outbound destinations received individual review. These are historical observations from the 2023 lab capture, not current reputation claims.

Historical destination	Observed traffic	Context recorded during the investigation
176.123.9.169	Connection to port 9001 and a TLS handshake	Followed TCP data contained several domain-like values; reverse lookup returned no record, and historical service data showed port 9001
142.132.254.39	Connection to port 8999 and a TLS handshake	Reverse DNS resolved into Hetzner-hosted infrastructure
212.47.233.86	Connections associated with ports 9001 and 9030	Historical service information identified the host as a Tor relay
128.31.0.39	SYN followed by RST, ACK, repeated before termination	Reverse DNS identified an MIT CSAIL host; the capture showed failed contact rather than a completed session
5.9.159.14	Connection attempt with no response	Reverse DNS pointed to hosting infrastructure, but the capture did not establish what role the host played

I treated each connection outcome separately:

• a completed TCP and TLS setup showed that the remote service accepted a session;
• RST, ACK showed that a connection was actively rejected or closed;
• repeated SYNs without a reply showed attempted contact but no completed session;
• reverse DNS and Shodan supplied historical context, not proof of malicious ownership.

That distinction matters during incident response. Failed communications can still support intent, configuration and retry behaviour. They should not be described as successful command-and-control sessions.

The capture also showed why address-only blocking has a short life. Tor relays and shared hosting infrastructure change. An old address may later belong to a different system or support legitimate traffic. I would use the addresses for historical scoping of this execution, but build detection around the originating process, destination rarity, connection timing and the host changes that occurred immediately beforehand.

Several outbound connections therefore used ports and hosts associated at the time with Tor relay infrastructure. Some attempts completed a TLS handshake, while others were reset or received no response. Reverse-DNS and historical service information provided context, but the destination addresses alone were not reliable long-term indicators. Tor relay membership changes, shared infrastructure can serve legitimate users, and old addresses lose value quickly.

The network evidence supported the behavioural finding that the sample attempted to establish Tor-based communication. It also demonstrated the limits of relying on a single data source:

• encryption concealed application content from simple packet inspection
• failed connections still revealed intent and retry behaviour
• domain and IP reputation was time-dependent
• process context was needed to connect traffic to the ransomware

For detection, the sequence was more useful than a static blocklist: a newly executed binary dropped resources, created related processes, changed the host, and then initiated unusual encrypted outbound connections.

Indicators as an investigative set

The assignment included host, string, import, and hash indicators. I grouped them by what they represented rather than treating every value as equally durable.

File and host indicators included tasksche.exe, taskdl.exe, taskse.exe, 0000000000.ekey, 0000000000.pky, 0000000000.res, the *.wnry extension, ransom-note components, registry persistence, desktop changes, and the WannaDecryptor process family.

Static indicators included the sample hashes, the WNcry@2017 archive string, unzip 0.15, inflate 1.1.3, misleading DiskPart metadata, resource structure, and imported APIs.

Behavioural indicators included resource extraction, startup persistence, file-permission changes, shadow-copy deletion, process creation, file encryption activity, and Tor-related network connections.

I did not treat the indicators as interchangeable. A sample hash gives high-confidence identification for one exact file but is easy to change. A filename or string is useful but can collide or be altered. The resource-extraction, process-creation, registry, file-encryption, and network sequence is harder to reduce to one value and gives an analyst more context.

I have not published the exact sample hashes or an unexplained indicator dump. The useful public material is the analysed historical behaviour and its detection context.

Detection opportunities across the evidence

The investigation supported detections at several points in the execution chain:

Data source	Detection opportunity
File scanning	Known sample hashes, misleading metadata, unusual resource content, and archive or tool strings
Process telemetry	A DiskPart-labelled executable spawning WannaDecryptor components and bundled utilities
Registry telemetry	Creation or modification of stored working-path and startup state
File-system telemetry	Dropped tools, key-related files, ransomware extensions, and widespread write activity
Memory telemetry	The parent-child process tree, key-file handles, dynamically resolved functions, and local process communication
Network telemetry	New processes initiating repeated encrypted connections to unusual infrastructure and Tor-associated ports
Recovery telemetry	Attempts to remove volume shadow copies alongside ransomware file activity

No single observation carried the whole classification. The confidence came from correlation: the executable’s structure predicted resource and registry behaviour; live execution produced the related process and file changes; memory preserved handles and arguments; and the packet capture showed the corresponding outbound attempts.

Detection hypotheses

The evidence supported several hypotheses that could be translated into endpoint or SIEM logic.

Resource carrier and child-process sequence

Look for a newly executed PE that writes multiple executables or archives into one working directory, changes permissions on that directory and launches the extracted components within a short interval.

Misleading system-binary identity

Alert when an executable presenting itself as a Windows utility runs from a user-controlled or unusual directory and creates ransomware-related child processes. The path and signature matter more than the displayed filename alone.

Ransomware file activity

Correlate a rapid increase in file writes or renames with creation of *.wnry files, key-related artefacts, desktop changes and recovery-inhibition commands. High-volume file writes have legitimate causes, so the supporting sequence is important.

Persistence and retained state

Monitor unexpected registry creation or modification by the launcher or its children, especially where the value stores a working path and occurs shortly before additional executables are launched.

Unusual encrypted egress

Detect a newly observed process initiating repeated TLS connections to rare external infrastructure or Tor-associated ports after dropping files and modifying the host. This is stronger than blocking a historical list of IP addresses.

For each detection I would record likely false positives. Installers can unpack archives, update permissions and create child processes. Backup software can generate heavy disk activity and interact with shadow copies. Privacy tools can contact Tor relays legitimately. The malicious confidence comes from the combined timeline and the identity of the initiating process.

Incident-response use

The analysis can be converted into an investigation sequence for a live alert:

1. identify the parent process, path, signature and hash;
2. isolate the host if widespread file modification is active;
3. preserve volatile evidence before rebooting when operationally possible;
4. collect the process tree, command lines, loaded modules, handles and network connections;
5. search for the dropped executables, key-related files and ransomware extensions;
6. review registry and startup changes;
7. scope equivalent activity across endpoints;
8. examine outbound traffic originating from the affected process tree;
9. protect recovery systems and confirm backup integrity;
10. rebuild or restore the host according to the organisation’s ransomware procedure.

The static strings and exact hashes could accelerate identification of this historical sample. The behavioural sequence would remain more useful if the file had been repacked or renamed.

Findings

The combined analysis classified the sample as WannaCry ransomware and reconstructed the following behaviour:

1. The initial executable presented itself as a Windows utility.
2. It located and unpacked embedded resources, including an encrypted archive and supporting tools.
3. Registry and file operations established working state and persistence.
4. The launcher created WannaDecryptor processes and changed the desktop and file system.
5. Memory artefacts recorded the process tree, open handles, command-line state, and local network activity.
6. Packet analysis showed attempts to communicate over encrypted connections associated with Tor relay infrastructure.

Static analysis explained what the program appeared capable of doing. Dynamic evidence showed which components ran. Memory and network analysis then connected the host changes to active processes and communication attempts.

Project boundaries and limitations

Known historical family

VirusTotal already classified the sample as WannaCry. The project demonstrated independent analysis of its structure and behaviour; it was not original family discovery or attribution.

Supplied executable rather than the complete campaign

The work concentrated on the supplied launcher and the components it unpacked. It did not reconstruct the initial infection route, exploit delivery, EternalBlue propagation or the complete campaign infrastructure.

Limited encryption analysis

I identified the setup around resource extraction and the transition into encryption, but I did not fully reverse the file-selection logic, cryptographic implementation or key lifecycle. No claim is made that the project recovered a decryption method.

One controlled execution window

Dynamic behaviour depends on operating-system state, privileges, time, network availability and the exact sample. One execution cannot prove that every branch ran or that all possible artefacts were created.

Single memory snapshot

The RAM image preserved one point in time. Short-lived processes, transient strings and completed connections may have disappeared before acquisition, while later behaviour would not yet be present.

Historical infrastructure context

The IP addresses, reverse-DNS results, Shodan observations and Tor-relay context belonged to the 2023 analysis. They should not be treated as current malicious-infrastructure claims.

External sandbox dependence

Intezer provided useful behavioural context, but I did not treat its labels as local proof. In a modern repeat I would export the raw sandbox events and map every accepted claim back to an observable result.

Tooling available at the time

I used the tools available in the module. A stronger modern workflow would add Procmon, API monitoring, debugger traces, automated configuration extraction, YARA development and repeatable detonation orchestration.

Further analysis

The next stage would be deeper debugging of the encryption and communication routines using a controlled debugger such as x64dbg. I would trace the transition from setup into file processing, identify how target paths are selected, inspect key material in memory and record how components exchange state.

I would also:

• collect staged memory captures;
• compare clean and infected filesystem and registry snapshots;
• automate extraction of PE resources and configuration;
• create YARA rules from stable structural features rather than one string;
• translate the process and registry sequence into tested endpoint detections;
• validate network detections against benign Tor and installer activity;
• map the observed behaviour to current ATT&CK techniques with evidence references;
• test the rules against repacked or renamed variants without executing them on real data.

What I developed through the project

This investigation developed practical experience in:

• handling a malicious sample inside an isolated lab;
• inspecting PE metadata, sections, resources and imports;
• using static clues to form dynamic-analysis questions;
• navigating decompiled C and generated function names in Ghidra;
• assigning analytical function labels without presenting them as original symbols;
• tracing registry, file, process and resource behaviour across call sites;
• monitoring an active Windows process tree;
• acquiring and analysing a memory image with Volatility;
• connecting handles and command lines to on-disk artefacts;
• following TCP streams and interpreting completed, rejected and unanswered connections;
• separating historical reputation from packet-level evidence;
• grouping indicators by durability and investigative value;
• building detection ideas from correlated behaviour rather than an unexplained IOC list.

The main lesson was that malware analysis becomes useful when the evidence is connected. VirusTotal named the family, but it did not explain the launcher. The import table suggested resource and registry activity, but it did not prove execution. Ghidra explained the preparation path, live monitoring showed the child processes and file impact, memory preserved runtime relationships, and Wireshark showed the outbound attempts.

That correlation is the part of the project most relevant to my current work. A SOC investigation rarely begins with every answer. It begins with partial evidence from different tools, and the analyst has to establish which observations belong to the same execution chain, which claims remain uncertain and which evidence can be turned into a useful detection or response action.

This remains a historical 2023 university analysis. The malware infrastructure and tooling have changed, but the workflow still applies: establish identity, inspect structure, observe execution, preserve volatile evidence, analyse traffic and correlate the results before drawing conclusions.