1 Introduction

Malware was alwaysa serious and ever-changing danger in the world, constantly targeting new weaknesses and organisations. This ever-changing environment has turned cybersecurity into a perpetual cat-and-mouse game, with security analysts and malware researchers competing to outmanoeuvre one another. Unfortunately, malware researchers frequently have the upper hand, forcing security professionals to react to emerging threats. To combat this, there is an urgent need for additional people to conduct proactive malware research and work on preventative approaches. Understanding how malware spreads is essential for countering its impacts. While research on external propagation is well established such as [1,2,3,4], research on malware transmission within local area networks frequently relies significantly on sophisticated mathematical models, making it less accessible to cybersecurity enthusiasts from varied backgrounds. The goal of this paper is to visualise malware propagation utilising variables and characteristics from devices on local area networks, giving a more user-friendly manner to understand the nature of propagation and aid in security decision-making.

This paper has two key goals that complement one another: contributing to a thorough understanding of malware propagation and improving response approaches during active attack events. The primary goal is to create clear and understandable visualisations of malware propagation. These visualisations serve several functions. For starters, they help other researchers develop advanced anti-malware capabilities by providing clear insights into how malware spreads. Researchers can create more effective defences and develop targeted solutions to combat malware threats by analysing the dissemination patterns. Second, visualisations are critical in informing decision-makers about the adoption of network security features. Decision-makers can implement security solutions more effectively if they understand how malware flows through networks. This helps them to effectively and proactively protect their systems, lowering the risk of malware outbreaks and potential damage. Furthermore, the visualisations help researchers grasp virus behaviour and its impact on networks. These visualisations support research goals by simplifying complex propagation patterns, allowing researchers to better understand the complexities of malware threats. The second goal is to discover significant characteristics of malware transmission to improve response times during active attack events. This analysis dives into several critical areas of malware distribution. First, it investigates whether malware spread is deterministic in some cases. Responders can anticipate malware behaviour and build preventative measures by researching whether it follows predictable patterns in certain circumstances. Second, the paper investigates the effect of Internet Protocol (IP) address location on propagation. Understanding how IP address features influence malware distribution allows responders to concentrate their efforts on vulnerable locations, increasing the efficacy of their response approaches. Furthermore, the paper looks into how network structure affects propagation. Responders can design networks that are better equipped to limit the risk of rapid spread and contain malware outbreaks by understanding the role of network architecture in malware propagation. Finally, the paper investigates how the study’s findings might be utilised to respond proactively to active threats. Consider approaches such as dynamically disconnecting machine clusters or deploying HoneyPots and HoneyNets for greater network protection and better malware event observation. Finally, by using enhanced visualisations, we hope to gain a better understanding of malware and its transmission patterns. At the same time, it aims to uncover critical traits that will allow responders to mount proactive defences against active threats. The findings of this paper have the potential to transform decision-making processes and response approaches, thereby improving network security and reducing the effect of malware attacks.

The paper is structured into six main sections to comprehensively explore the study’s objectives and findings. Section 1 sets the stage by providing an overview of the research goals and the significance of clear and interpretable visualizations in understanding malware propagation and improving response strategies. In Sect. 2, the existing literature on malware propagation and analysis methodologies is reviewed, laying the foundation for the study and highlighting the contribution of this research in addressing specific gaps. Section 3 is further divided into several sub-sections: Sect. 3.1 explains the step-by-step approach taken to achieve the goals, encompassing tool development, data collection, and analysis phases. Section 3.2 addresses the ethical implications of working with actual malware samples and ensuring a secure sandbox environment. Section 3.3 details the setup used for collecting data, while Sect. 3.4 outlines the strategy for observing and visualizing malware activities. Section 4 delves into the results and observations obtained from testing different malware samples. Sub-sections (Sect. 4.1–4.7) present detailed analyses of specific malware variants, such as WannaCry, CryptoLocker, Locky, Petya, NotPetya, and NotPetya Extended, highlighting their propagation behaviours and effects on the network. In Sect. 5, the study’s contributions are discussed in two sub-sections: Sect. 5.1 emphasizes the success of the visualizations in conveying relevant metrics clearly, while Sect. 5.2 reflects on the research questions, conclusions, and potential areas for improvement. Section 5.3 explores potential avenues for further research and development, building on the research’s insights and limitations. Finally, in Sect. 6, the paper offers a concise summary of the research’s key findings, the effectiveness of the visualizations, and the implications of the study’s outcomes for understanding malware propagation and enhancing response strategies. The conclusion also serves to reiterate the significance of the research in advancing the field of cybersecurity and malware analysis.

2 Related Works

The majority of malware propagation research hhadas a strong mathematical focus, which wasstill important to this topic. Understanding existing knowledge on malware spread aids in the formulation of hypotheses and the validation of our findings and those of other researchers. Yu et al. [5] used epidemic theory and a two-layer epidemic model to investigate malware propagation. In contrast to control system theory, which tries to identify and contain malware transmission, they concentrated on epidemic modelling because it is more concerned with the number of compromised hosts and their dispersion. In their study, Yu et al. [5] differentiated between epidemiological studies that examine malware transmission and control system studies that try to prevent proliferation. Their findings indicated three stages in large-scale network propagation: an early exponential distribution, a late power law distribution with a short tail, and a final power law distribution. Guillen and Rey [6] expanded on Yu et al. [5] work by recognising the significance of “compartment devices” that can spread malware without being infected directly. When researching malware behaviours in networks containing compartment devices, this observation emphasises the importance of network trace analysis. Hosseini and Azgomi [7] developed a model that identifies different system states during malware propagation using a rumour-spreading approach. This approach facilitates classifying the roles of machines in an active attack on a local area network and may be useful in visualisations. Zhuo and Nadjin [8] created the “MalwareVis” tool to visualise malware network traces, with an emphasis on specific attributes such as protocol and IP address. While their research provides insights into complicated malware analyses, it may be difficult for newcomers to comprehend without a thorough understanding of the underlying formulas. Gove and Deason [9] used a unique approach based on discrete Fourier transforms to detect malware-related network behaviour. Their approach is sophisticated but exciting, as it permits malware detection in difficult settings. Afianian et al. [10] summarised common tactics used by malware to avoid detection and investigation. Chakkaravarthy et al. [11] investigated malware detection approaches within the network, focusing on payload fragmentation and session splicing. Miramirkhani et al. [12] investigated artefacts used by malware researchers to detect a virtual environment on sandbox machines. Sharafaldin et al. [13] developed a labelled dataset for intrusion detection systems that contain network traffic attributes that can be used to detect benign or intrusive flows. Creese et al. [14] visualised enterprise network attacks and their potential effects, providing useful insight into the approach of our paper. Nataraj et al. [15] used byte plot visualization as grayscale images for automatic malware detection. They achieved 97.18% accuracy using GIST features and the K-nearest neighbor algorithm. Naeem et al. [16] proposed an image-based malware detection system that uses D-SIFT and GIST features. They achieved 97.4% accuracy but limited their analysis to Windows malware only. Su et al. [17] developed a lightweight neural network for distinguishing DDoS malware and goodware in IoT applications. They achieved 94% accuracy but had a limited dataset. Makandar and Patrot [18] proposed a SVM classification using wavelet transform and GIST features, achieving 98.84% and 98.88% accuracy for KNN and SVM, respectively. Han et al. [19] analyzed malware using entropy graphs with bitmap images for classification. Limited to Windows portable executable files and cannot detect packed malware samples. Tuncer et al. [20] proposed a model for malware classification using hybrid features like singular value decomposition and local binary patterns. Achieved an 88.08% accuracy rate. Various deep learning-based approaches were presented by different researchers. For instance: Robert et al. [21] used CNN to classify malware traffic with 91.32% accuracy. Bendiab et al. [22] employed a deep CNN to identify malicious network traffic in IoT environments with 94.5% accuracy. Kalash et al. [23] designed a deep CNN model for malware categorization achieving high accuracy rates on different datasets. Cui et al. [24] used CNNs to classify malicious code binaries achieving 97.6% accuracy. Wang et al. [25] applied deep learning to improve malware analysis for detecting zero-day threats. The study of these various methodologies and characteristics in malware propagation, evasion strategies, and malware analysis approaches will be critical for the methodology and visualisation tool of our study. Table 1 contains a summary of the aforementioned studies.

Table 1 Summary of Studies on Malware Propagation and Detection Approaches
Full size table

3 Methodology

Since there is a clear sequence of dependency among the goals, this paper wasuse a linear approach to achieving them. The paper’s evolution was determined by this dependency rather than personal taste. Each goal was addressed sequentially, ensuring that the essential groundwork is created before proceeding to the next phase. This approach was for the goals to be met seamlessly and systematically, maximising the effectiveness of the research and visualisation tool creation.

3.1 Methodology and Phases of the Study

The paper wasproceed in a linear order, with different phases leading to the achievement of the goals. The first phase entails developing a tool to extract system details and possibly the moment of infection from an affected machine for later malware propagation research. Before developing the solution, an extensive study on malware analysis methodologies for sandbox environments was undertaken to verify that the virtual environment used for testing prevents malware from spreading outside the virtual environment. Understanding how to mislead malware with lower context awareness approaches wasalsoinvestigated. Vulnerabilities exploited by malware to exit virtual environments wasalso investigated, both to avoid them and, if time allows, to study them. Once built, the tool was tested on non-infected systems first, followed by testing on systems under active attack, in accordance with the first goal. Following that, the tool was deployed to extract data from devices that are actively being attacked, and continual development may be required to adapt the tool to varied malware behaviors, in accordance with goal three. The third phase is analysing, visualising, and making conclusions from the results while sticking to the criteria given in goal two. Phases two and three may be repeated numerous times, with each run analysing a different piece of malware, depending on the amount of spare time.

3.2 Ethical Considerations

This paper discussedtwo ethical issues, one of which wasa demand and the other a declaration. Because we are working with actual malware samples, the sandbox environment had to be highly secure to prevent malware dissemination outside of the controlled environment. A less secure sandbox could represent a risk to home, business, or school networks, putting devices connected to those networks at risk. As a result, it wascritical to optimise the sandbox environment and extensively investigate the malware samples for any context-based attacks that might compromise the external network. The declaration i was that no malware wouldbe created as a result of this paper. This research will only looked at existing malware variants that had been already investigated and avoided. The same ethical issues applied to testing setup, and it was critical to provide a secure and regulated environment to avoid any unexpected repercussions of malware transmission.

3.3 Data Collection and Network Configuration

A three-tiered approach was used to collect the data required for visualising malware activities and dissemination. The first two approaches entailed utilising a specially designed program to collect metrics from all running virtual machines every five seconds and to record screenshots of the current view every thirty seconds. This approach allowed us to monitor resource utilisation in the background and identify any substantial changes in the foreground during runtime. When we ran a WannaCryFootnote 1 sample, for example, we could see resource spikes throughout the encryption process and the display of the ransom letter thereafter. The third way of data collection involved utilizing WireSharkFootnote 2 to record communications between devices on the testing network. WireShark was installed on a second node and ran in promiscuous mode while monitoring the primary network device. This allowed us to keep track of all activity between the nodes as shown in Fig. 1. The network configuration for this paper will be simple, consisting of a local area network with four vulnerable Windows 7 virtual machines. These machines were purposefully set up to be as vulnerable to malware transmission as possible. On the network, each virtual machine had an open, password-less, limited encryption fileshare, all ports open, and user access control deactivated. On the network, a fifth node running Ubuntu 20.04 LTS was set up, running WireShark in promiscuous mode. To avoid malware spreading to the host machine, the complete network was constructed within Oracle Virtualbox’s internal network setup. The Ubuntu system was the only one with access to the external host, and it used a Virtualboxfileshare to extract the network activity. During active testing, this fileshare wasdisabled and deleted, and it was only be mounted and reopened after testing was completed and the infected devices were reverted.

Fig. 1
figure 1

Network Architecture

Full size image

3.4 Quantitative Testing Approach

The testing wasbe mostly quantitative, to observe and visualise the activity and dissemination of multiple malware samples. The goal was to obtain a thorough understanding of the malware landscape and adequately demonstrate the capabilities of our setup. While the emphasis was on breadth, the findings were not be lacking in depth. Each sample was to be analysed using one of the three ways, and the network log provided a variety of factors to investigate, including alternative protocols. All of the samples utilised in the testing were obtained from TheZooFootnote 3, an online malware collection. Each sample was tested for a total of twenty minutes, including ten minutes of general activity and ten minutes with the sample actively running on node 1. Additional time, roughly ten minutes each wasallotted for setup and teardown, resulting in a total testing time of around forty minutes, assuming no issues. This time frame was designed to make quantitative approaches easier to apply and to standardise the analysis time. It wasunderstood that certain samples may not activate during the testing time; this was investigated and duly noted to understand any usual or abnormal conduct.

4 Experimental Analysis

In this section, we ran tests with several malware samples and collect important metrics using the previously specified configuration. Our malware samples came from a variety of sources. The major source wasTheZoo malware repository on GitHub. TheZoo is a community paper dedicated to collecting and cataloguing various malware samples and variants. Furthermore, we used the MalwareDatabaseFootnote 4 collection, which was maintained by a user named NTFS123 and contained unique samples not available in TheZoo, such as different versions of WannaCry. We used a variety of technologies in conjunction with our dashboard programme to validate certain attributes or versions of the malware samples. VirusTotalFootnote 5, developed by HispasecSistemas, is one such tool. We were able to use file or Uniform Resource Locator (URL) submissions to analyse suspicious files or links and compare them to other entries with similar looks. It was especially beneficial in distinguishing between malware samples that appeared similar but had fundamental differences. To read the full details of the samples used in the following section, enter their MD5 hashes into VirusTotal. The CuckooFootnote 6 sandbox environment, an open-source automated malware analysis environment, was also used in our research. Cuckoo functioned as a stand-in for our setup. If a sample looked to be inactive in our environment but VirusTotal reports indicated otherwise, we would run it in the Cuckoo sandbox to evaluate any potential contextual awareness capabilities displayed by the malware.

4.1 WannaCry (Wormless)

A wormless variation of WannaCry was used to fine-tune data collection throughout the development phase. Because this variation lacks the payload’s worm component, it cannot spread over a network like its infamous sister that exploited the EternalBlue vulnerability [26]. The wormless variation was chosen to save test tear-down time during development while still ensuring that data was recorded by the dashboard. WannaCry was ideal for this purpose since it exhibits rapid and easily identifiable activity, making it simple to pinpoint certain times in time. Several tests were run throughout the development process, and adjustments and enhancements were made along the way. At first, the tests simply featured the four nodes and the dashboard program. The final test, however, included the Ubuntu node to capture network events. A test with only one infected machine was visualised for clarity and understanding of the unique activities of an infected system compared to uninfected ones. This gives us an idea of how our network visualisations would look, especially when compared to subsequent tests including numerous infected workstations, which can cause network activity to become highly chaotic. Figure 2 depicts node 1’s infection and subsequent data encryption activity. The heightened activity lasts for the duration of the game. Notably, nodes 3 and 4 witness an increase in activity for unknown reasons. Because the sample lacks the worm component, it cannot propagate to these nodes, leading us to believe that the increased activity is due to concurrent network activity of some kind, while the exact source is unknown. Surprisingly, despite the absence of the worm component and the EternalBlue attack, the infected node 1 attempts to connect to node 2, as seen in Fig. 3. This implies that the sample can seek the Server Message Block (SMB) vulnerability and make connections, but not exploit it. This action raises concerns about the nature of this WannaCry sample, leading us to hypothesise that it could be a neutered sample with the worm component removed or from an older version of WannaCry before the worm component was implemented. While it may appear improbable, we prefer the former explanation because it appears more believable for a malware sample. Figure 4 depicts Simple Service Discovery Protocol (SSDP) activity that looks to be quite typical, with no evident anomalies in its nature. This is to be expected, as the underlying operating system (Windows in this scenario) would still be functioning and regular network protocols would continue to function during the ransomware encryption process. It stands to reason that ransomware that affects the entire operating system, such as Petya/NotPetyaFootnote 7, will cause more severe aberrations in network activities. Figure 5 depicts Transmission Control Protocol (TCP) activity across the network. Node 4 received and created no TCP activity for some unknown reason, which could simply be a coincidence. Notably, there are several TCP connections established between IP addresses 192.168.0.10 and 192.168.0.11. We also see that the first round of TCP connections collected between 192.168.0.10 and 192.168.0.11 resembles the first round of TCP connections captured between 192.168.0.12 and 192.168.0.11. This implies that the initial round of communication is typical. The third mass of TCP connections, on the other hand, wasnot like its predecessors. As SMB operates on top of TCP, we hypothesise that this is the connection collected during the SMB activity. This notion wasbacked further by the following erratic and continuous TCP activity, which replicates the SMB graph. The User Datagram Protocol (UDP) and browser activity, illustrated in Figs. 6 and 7, appeared to be fully normal, lending credence to the concept that normal network activity coexists with the expected infected behaviour.

Fig. 2
figure 2

WannaCry Wormless

Full size image
Fig. 3
figure 3

WannaCry Wormless SMB Activity

Full size image
Fig. 4
figure 4

WannaCry Wormless SSDP Activity

Full size image
Fig. 5
figure 5

WannaCry Wormless TCP Activity

Full size image
Fig. 6
figure 6

WannaCry Wormless UDP Activity

Full size image
Fig. 7
figure 7

WannaCry Wormless BROWSER Activity

Full size image

4.2 WannaCry (Wormless)

WannaCry, also known as WannaCryptor, was selected as the first propagating sample for observation and visualisation. Before Marcus Hutchins discovered its killswitch in 2017, it caused substantial damage. The National Health Service (NHS) in the United Kingdom reported that it infected 603 primary care and other NHS organisations and deactivated 1220 diagnostic devices to prevent future contamination. Because of its capacity to rapidly disseminate utilising the SMB vulnerability, WannaCry was a perfect pick for the first test. WannaCry actively monitors the network for open SMB ports (445) and uses the EternalBlue vulnerability to propagate to additional machines after infecting the first machine. It can even infect machines that are already infected. The first metric examined was CPU use across all network nodes. The hypothesis was that when WannaCry began encrypting, CPU consumption on a single node would noticeably increase, followed by successive jumps in CPU usage as the malware spread. Furthermore, a general rise in CPU used across all devices was expected as a result of the ransom note running and continual network scanning following infection. Figure 8 mostly confirms these hypotheses. The first ten minutes indicate irregular activity on node 1, which was most likely due to startup programmes upgrading or the node asking for its connection status. There was a big surge in activity on node 1 (blue) around the midpoint, indicating the deployment of the WannaCry sample. Followed by the spike of activity on node 1, there was an increases in activity on node 3 (green), followed by lesser spikes on nodes 2 (red) and 4 (orange). These initial increment signified infection and encryption points that occured within two minutes. Following that, there wasa general increase in CPU utilisation across all nodes, with repeated spikes, which mightbe due to WannaCry’s re-infection behaviours. The visualisation in Fig. 9 depicts WannaCry’s SMB activity across the four nodes. When a node is the source of an SMB activity, the orange colour denotes the source, while the blue colour represents the destination. The purple lines reflected the SMB activity’s direction. The infection begun on node 1, and WannaCry spreaded to node 3. It extended from there to node 4 and finally to node 2. The subsequent SMB activity can be attributed to infected workstations seeking to reinfect the network’s previously infected machines. One intriguing discovery wasthe behaviour of node 1, which first talked with node 3 and later showed lower activity saved for interactions with nodes 3 and 2. The cause for this unique pattern wasunknown, although WannaCry is notorious for being loud and active due to its ransomware nature. TCP activity (Fig. 10) appeared to be similar to the later half of the SMB graph distribution. This resemblance wasunderstandable given that the SMB protocol runs on top of the TCP protocol on port 4445, which wasabused by this variant of WannaCry. As a result, the first half of the graph depicted general TCP activity, whereas the second half depicted both general and SMB-related activity. However, without prior knowledge about SMB activity, Fig. 10 was insufficient to identify whether propagation had happened. In a WannaCry-infected network, the SSDP visualisation indicated no notable deviations or irregularities as shown in Fig. 11. It appeared to function regularly and consistently, making determining the specific site of dissemination difficult. Similarly to SSDP, there was no discernible activity within UDP, BROWSER, or HTTP that indicated WannaCry dissemination as shown in Figs. 12, 13 and 14. After infection, all of these processes behave consistently. In terms of screenshot collection, as shown in Fig. 15, we estimated that the duration between a clean network and full infection is about two minutes and thirty seconds. As shownby the final Fig. 16 acquired in this test, the visualization demonstrated WannaCry’s inclination to reinfected previously afflicted machines. With further examination utilising Cuckoo as shown in Fig. 17, unexpected findings revealed that WannaCry demonstrated contextual awareness. According to Cuckoo, WannaCry was found specifically searching for the Cuckoo agent.py in the starting directory, indicating its ability to locate its testing environment.

Fig. 8
figure 8

WannaCry Network CPU Usage

Full size image
Fig. 9
figure 9

WannaCry Network SMB Activity

Full size image
Fig. 10
figure 10

WannaCry Network TCP Activity

Full size image
Fig. 11
figure 11

WannaCry Network SSDP Activity

Full size image
Fig. 12
figure 12

WannaCry Network UDP Activity

Full size image
Fig. 13
figure 13

WannaCry Network BROWSER Activity

Full size image
Fig. 14
figure 14

WannaCry Network HTTP Activity

Full size image
Fig. 15
figure 15

WannaCry Network Clean to Infected

Full size image
Fig. 16
figure 16

WannaCry Possible Reinfection

Full size image
Fig. 17
figure 17

WannaCry looking for Cuckoo

Full size image

4.3 CryptoLocker

In this paper, we examined three versions of CryptoLockerFootnote 8, which emerged in September 2013, November 2013, and January 2014, respectively. However, during our tests, none of the CryptoLocker ransomware variants executed their payload within the twenty-minute time frame. Upon further investigation, we discovered a unique reason behind this behaviour. Once launched, the CryptoLocker ransomware created a visible process in the task manager, inserts itself into the startup programs, and then deletes the original executable that initiated these processes. This observation was evident in the task manager (Figs. 18 and 19). While we expected no internal propagation within local area networks, we did not anticipated the lack of encryption, which revealed an intriguing situation. After removing the injection method, CryptoLocker was requiredto communicate with its command and control server, known as the GameOver ZeuS server. During this communication, the server registers CryptoLocker as part of its botnet and generated 2048-bit RSA keys, which was sends back to the CryptoLocker on the client side to initiate file encryption. This situation presented two interesting scenarios: first, the GameOver ZeuS server was taken down in 2014, rendering any communication with the server impossible; second, even if the server were hypothetically available, our testing setup operates within an internal network structure, making it unable to communicate with the server. Consequently, we encountered an unforeseen difficulty, as malware requiring external influence to perform its full function would not operate entirely within our setup. In essence, our system flaw lies in its suitability for testing dropper-type malware, while it may not be as applicable for downloader types or botnets.

Fig. 18
figure 18

September Variant Process

Full size image
Fig. 19
figure 19

January Variant Process

Full size image

4.4 Locky

In contrast to CryptoLocker, LockyFootnote 9 provided a projected difficulty in malware testing. Locky, like CryptoLocker, performs self-deletion after execution. Locky, on the other hand, has contextual awareness, which means it has numerous approaches for determining whether it is running in a virtual environment. During our test, the Locky sample self-destructed and did not perform any additional actions. We searched for all claimed infection indications in registry and system files but found none, leading us to conclude that this is the first time in our testing that a sample correctly identified that it was within a virtual machine and chose not to run. In a previous scenario, WannaCry demonstrated minimal contextual awareness by hunting for the Cuckoo agent in the starting directory. However, because it was not looking for the normal indicators of a virtual machine, it was able to execute in our configuration, which employs the Cuckoo environment, as shown in Fig. 20.

Fig. 20
figure 20

Locky Registry Changes Not Present

Full size image

4.5 Petya

NotPetya/ PetrWrap is the Petya variation to watch for potential propagation since it uses the SMB Eternalblue vulnerability to spread. To provide a full comparison, we first visualised the known non-propagating variation. Petya differs from normal ransomware in that it infects the master boot record, causing the system to boot into the ransomware rather than the operating system. As a result of the system becoming infected, rebooting, and encrypting the files, we should expect significant increases in CPU consumption as shown in Fig. 21. This test’s SMB activity is nearly identical to the SMB activity seen in the 5.2 WannaCry [Wormless] test. We initially suspected that the WannaCry sample was the start of the SMB EternalBlue worm’s implementation, however, the findings of our test have led us to reject that hypothesis. Instead, we attribute this unusual activity to erroneous SMB activity caused by our setup rather than by the samples as shown in Fig. 22. While this may interfere with our study of SMB activity from actual EternalBlue samples, we believe wasnot be materially deleterious because the 5.3 WannaCry analysis revealed that when a sample uses SMB to propagate, it generates highly loud and distinct activity. Similarly to the previous visualisations, there is little remarkable activity observed during the test in the TCP, UDP, SSDP, or BROWSER protocols as shown in Figs. 23, 24, 25 and 26. A deeper examination of network activity may uncover deviations from the norm, although, at first inspection, there are no significant differences between normal activity and the period when the sample is engaged and the environment is under active danger.

Fig. 21
figure 21

Petya CPU Usage

Full size image
Fig. 22
figure 22

Petya SMB Activity

Full size image
Fig. 23
figure 23

Petya TCP Activity

Full size image
Fig. 24
figure 24

Petya UDP Activity

Full size image
Fig. 25
figure 25

Petya SSDP Activity

Full size image
Fig. 26
figure 26

Petya BROWSER Activity

Full size image

4.6 NotPetya/PetrWrap

This Petya variant used several exploits, including the SMB vulnerability Eternalblue, as well as a backdoor in M.E.Doc accounting software and EternalRomance. Despite its aggressive propagation capabilities in real-world circumstances, we tested two variations of NotPetya in our environment, and while both successfully attacked node 1, neither was able to infect the other nodes. The CPU utilisation during NotPetya testing was noteworthy because it demonstrated unambiguous proof of activation and sustained activity after the malware was launched as shown in Fig. 27. Spikes in activity on other nodes also signalled possible propagation attempts. The SMB activity after activation suggested that the initially infected node was attempting to communicate with other nodes as shown in Fig. 28. The increasing TCP consumption supported NotPetya’s promiscuous nature even more as shown in Fig. 29. Standard network protocols, on the other hand, showed no deviations as shown in Figs. 30, 31 and 32. NotPetya caused a system restart to be delayed by creating a scheduled job for propagation, which may have occurred outside of the testing window. The next test concentrated on monitoring until the infected node reboots, delivering further information.

Fig. 27
figure 27

NotPetya CPU Activity

Full size image
Fig. 28
figure 28

NotPetya SMB Activity

Full size image
Fig. 29
figure 29

NotPetya TCP Activity

Full size image
Fig. 30
figure 30

NotPetya UDP Activity

Full size image
Fig. 31
figure 31

NotPetya SSDP Activity

Full size image
Fig. 32
figure 32

NotPetya BROWSER Activity

Full size image

4.7 NotPetya Extended

Because of its distinct operating style, NotPetya worked differently from other ransomware. It stalls spread by infecting additional machines in the network after the first infection and organising a lockdown via forced restarts. NotPetya successfully spread to all machines on the virtual network in our modified tests. The CPU utilisation during the longer test demonstrates a clear infection pattern, with activity reverting to normal levels after infection until the synchronised restart initiates the file encryption process as shown in Fig. 33. NotPetya’s SMB and TCP operations are denser and more frequent than WannaCry’s as shown in Figs. 34 and 35. Standard approaches, on the other hand, indicate consistent and normal activity bothbefore and after infection as shown in Figs. 36, 37 and 38. It wasclear that our current testing approach has limits, and a qualitative approach may be more appropriate in future studies to comprehend malware processes and encourage complete payload deployment.

Fig. 33
figure 33

NotPetya Extended CPU Activity

Full size image
Fig. 34
figure 34

NotPetya Extended SMB Activity

Full size image
Fig. 35
figure 35

NotPetya Extended TCP Activity

Full size image
Fig. 36
figure 36

NotPetya Extended UDP Activity

Full size image
Fig. 37
figure 37

NotPetya Extended SSDP Activity

Full size image
Fig. 38
figure 38

NotPetya Extended BROWSER Activity

Full size image

5 Discussions

In this section, we examined the findings in light of the goals stated in the introduction section of this paper. In addition, we looked into any additional interesting observations and emphasise the most important discoveries from the testing phase.

5.1 Effective Visualizations

Our primary goal was to produce clear and simple propagation visualisations. We expanded this goal throughout the development process to incorporate a larger perspective while still attaining the same purpose. Instead of focusing exclusively on visualising observed propagations, we intended to collect metrics and logs to form judgements about whether or not propagations occurred. This move allowed us to examine the effects of malware propagation on the network rather than just displaying the infection’s pathways. We believe we have succeeded in developing clear and interpretable visualisations. Each visualisation efficiently conveys relevant metrics in appropriate formats. Using multi-line charts to show CPU utilisation across nodes, for example, proved to be a simple yet effective means of communicating changes in values over time. The presentation of the values together allowed for easier comparisons between nodes. Furthermore, in accordance with the ideas outlined in Raffael Marty’sFootnote 10 book “Applied Security Visualisation”, we displayed typical activities for comparison before adding malware and by evaluating samples without network propagation capabilities. Our visualisations improved over time, adding features such as labels, legends, and IP addresses to increase readability and provide a clearer view of the network’s condition. Despite these advances, we recognise that our visualisations are not perfect. The visualisations of network logs, in particular, might benefit from fine-tuning to properly depict the difference between transmitting and receiving IP addresses. Furthermore, when applied to bigger networks, the scalability of the CPU utilisation graphs may be an issue. Overall, we feel that our visualisations fulfil a fundamental role of informing, instructing, and assisting in study and decision-making. We can improve the visualisations with additional study and tweaks to contribute at a better level.

5.2 Addressing Research Questions and Limitations

Our second set of goals included explicit questions about certain qualities and use situations, which we will now address in order. Based on our research, we believe malware propagation is not completely deterministic. While malware may search for IP addresses that are similar to its own, other factors such as speed can influence the order in which it spreads. In our WannaCry experiments, for example, 192.168.0.12 became infected before 192.168.0.11, most likely because it received and accepted the SMB connection faster than the others. As a result of several contributing factors, the propagation order might appear random or pseudo-random. Unfortunately, due to restrictions in constructing virtual networks and hardware capability, we were unable to properly investigate the impacts of network structure on propagation. Our existing system and visualisations fall short of successfully responding to an active threat event. We collect data for later analysis and visualisation, but no real-time analysis or response is performed. Adapting our system to visualise real-time data would still introduce some latency, making it difficult to respond quickly to rapidly spreading attacks like WannaCry, which affected our four machines in less than two and a half minutes. While our visualisations can provide insights and generalisations for future decision-making under active danger, a real-time response system that can make effective decisions on its own would require extensive development and training.

5.3 Future Works

Several other discoveries were found throughout the testing phase that we believe are extremely significant. One such discovery is the contrast between malware’s external and interior dissemination approaches. External propagation happens when malware leaves the network to spread, whereas internal propagation occurs within the network by utilising exploits found in the operating system. Due to the lack of an internet connection in our testing environment, we were unable to investigate malware that relies on external connections, such as compromised email accounts or communication with command and control servers. Another point is the probability of overlooked cases as a result of our quantitative study’s standardised approach. Malware that targets specific programs rather than the operating system may not have been thoroughly tested or detected in our configuration. To solve this, further studies may need to be conducted over a longer period to alter the testing approach to suit such occurrences. We also looked into the concept of contextual awareness, which is when malware detects that it is executing in a virtual environment. While our reduced testing approach may miss certain human interaction artefacts, testing on real-world machines poses ethical challenges. Furthermore, modern evasion tactics are learning to recognise virtual environments such as VirtualBox and VMWare, which may have an impact on the effectiveness of our testing. These findings highlighted the importance of a balanced approach to malware research, taking into account external versus internal propagation approaches, and being aware of contextual evasion approaches. Future research should address these issues to improve the efficacy of malware testing and analysis.

6 Conclusions

We have made tremendous progress throughout this paper by developing a dashboard program capable of launching and collecting metrics from many virtual machines. We built visualisations that provide vital insights into the behaviour of hacked devices and their impact on the overall network. Our findings pave the way for further research on malware spread and characteristics, particularly in the context of Windows 7 operating systems. Moving forward, we will concentrate on improving the dashboard programme by seamlessly integrating real data visualisation on the same webpage. We intend to redesign the virtual network formation procedure to speed up testing phases and reduce setup and tear-down time. In addition, we intend to investigate other approaches for acquiring metric data and devise approaches to prevent malware’s contextual awareness. In addition, we will continue to develop our visualisations to effectively explain findings and provide many possibilities for diverse points of view. Extending our research to include larger corporate networks will provide insights into active threats on interconnected systems with varying topologies. We invite other researchers to delve deeper into this topic and contribute to ongoing efforts to combat and understand malware.