DCmal-2025: A Novel Routing-Based DisConnectivity Malware—Development, Impact, and Countermeasures

Abstract

Operating systems such as Windows, Linux, and macOS include built-in commands that enable administrators to perform essential tasks. These same commands can be exploited by attackers for malicious purposes that may go undetected by traditional security solutions. This research identifies an unmitigated risk of misuse of a standard command to disconnect network services on victim devices. Thus, we developed a novel Proof-of-Concept (PoC) malware named DCmal-2025 and documented every step of its lifecycle, including the core idea of the malware, its development, impact, analysis, and possible countermeasures. The proposed DCmal-2025 malware can cause a Denial-of-Service (DoS) condition without exploiting any software vulnerabilities; instead, it misuses legitimate standard commands and manipulates the routing table to achieve this. We developed two types of DCmal-2025: one that triggers a DoS immediately and another that initiates it after a predefined delay before restoring connectivity. This study evaluated 72 antivirus detection rates of two malware types (DCmal-2025 Type 1 and Type 2) written in C and Rust using VirusTotal. The source code for both types was undetected by any of the antivirus engines. However, after compiling the source code into executable files, only some Windows executables were flagged by general keywords unrelated to DCmal-2024 behaviour; Linux executables remained undetected. Rust significantly reduced detection rates compared to C—from 7.04% to 1.39% for Type 1 and from 9.72% to 4.17% for Type 2. An educational institution was chosen as a case study. The institution’s network topology was simulated using the GNS3 simulator. The result of the case study reveals that both malware types could cause a successful DoS attack by disconnecting targeted devices from all network-based services. The findings underscore the need for enhanced detection methods and heightened awareness that unexplained network disconnections may be caused by undetected malware, such as DCmal-2025.

1. Introduction

In recent years, our lives have become increasingly dependent on Internet access, as many tasks previously completed in traditional ways are now performed online, such as shopping, learning, and banking [1,2,3]. Although online services make our lives easier and faster, they also open the door to numerous risks, such as cyberattacks. Cyberattacks are becoming increasingly frequent these days and can have serious consequences for individuals, businesses, or even governments [4]. There are different forms of cyberattacks, and malware is one of the most common of them. Malware can be downloaded onto a target system and executed without the user’s awareness. When a system is infected, it becomes vulnerable to serious issues such as sensitive data theft, unauthorized monitoring, or even having the device locked up [5,6].

The rapid spread of malware worldwide has become a serious problem for cybersecurity experts. Numerous reports from the cybersecurity community highlight that not only is malware appearing at a high rate, but it is also becoming more advanced and increasingly challenging for traditional antivirus software to detect. According to Deepstrike’s 2025 report on malware incidents from 2024 through May 2025 [7], cybersecurity systems are now detecting approximately 560,000 new malware threats every day. Meanwhile, AV-TEST’s report [8] shows that the AV-TEST Institute registers more than 450,000 new malware and potentially unwanted applications (PUAs) daily. These huge daily statistics are part of a larger trend, where, according to the report from [7], global malware infections are projected to rise from around 5.6 billion in 2020 to an expected 6.5 billion by the end of 2025. This significant increase over the years is driven by the growth of IoT vulnerabilities, AI-generated malware, and increasingly sophisticated phishing campaigns. In addition to these alarming infection rates, another report reveals the most common methods on which attackers rely when they target victims, as seen in [9]. The report indicates that approximately 68% of attacks are caused by malware, which is the most commonly employed in both organizations and individuals. Furthermore, the report shows that attackers use social engineering techniques in 52% of cases targeting organizations and 85% of cases targeting individuals, indicating that social engineering tricks are the most common tactic used to target both individuals and organizations. This demonstrates how heavily the attackers rely on deception to achieve their goals. The rapid expansion of malware creation poses a significant threat to system security, underscoring the urgent need to develop stronger defense systems to address new malware effectively.

These days, the increasing ability of detection tools makes the attacker’s job more complicated, especially if they still rely on traditional techniques and exploit known vulnerabilities to build their malware. As a result, they are now employing more advanced strategies and tactics to avoid detection and increase the harmful impact of their malware. Living off the land (LotL) is one of these modern techniques, which involves misusing the trusted built-in system tools, such as PowerShell, WMI, and scheduled tasks, or a trusted software that is easily installable. This misuse aims to carry out their malicious actions while blending in with normal operations, making this threat harder to detect and prevent [10,11,12]. In [10], Barr-Smith et al. analyzed more than 31 million Windows malware samples. They observed that 9.41% of the general malware samples used LotL techniques, and the most common type of samples that used this technique were Advanced Persistent Threat (APT) malware samples, with a prevalence of 26.26%, which is more than twice that of commodity malware. Additionally, industry data from CrowdStrike, published in CrowdStrike’s annual analysis of the threat landscape and adversary universe, show that in the final quarter of 2021, approximately 62% of CrowdStrike Security Cloud detections were malware-free, while attackers leveraged legitimate credentials and built-in tools to make this threat more advanced and bypass detection tools. These statistics demonstrate the significant dependence of malware developers on LotL strategies recently, which underscores the urgent need for more robust detection methods and careful checking of trusted software and operations that might pass unnoticed malicious actions within routine system activity.

The routing table is one of the system components that can be misused by malware. It plays a vital role in controlling the flow of data across a network [13,14,15]. Despite this critical role, previous research has not documented a standalone malware that manipulates the routing table to perform a Denial of Service (DoS) without launching a large-scale attack or relying on botnets. On the other hand, most existing research focuses on other types of malware, such as ransomware, spyware, or botnet-based threats [16,17]. To draw the attention of system defenders to the dangers of routing table abuse, in our study, we propose a novel Proof-of-Concept (PoC) malware named DCmal-2025. The name comes from “DisConnected” (DC), “malware” (mal), and the year of creation of this malware (2025). This new malware is standalone and independent, as it does not depend on any other services or components to execute its malicious activity. It is capable of causing changes in the routing table entries and inducing DoS conditions using legitimate system commands, which helps it remain undetected. The knowledge gained from this paper regarding this novel malware underscores the significance of our work in enhancing defensive strategies against malware of this kind. The DCmal-2025 malware becomes quite dangerous when it targets critical IT infrastructures (CITIs) that rely on continuous network availability, as their connection with services is crucial for maintaining people’s lives, health, wealth, and everyday activities. These kinds of systems are susceptible to any breaches or hazards, where a breach in at least one node in CITI may affect interconnected services and cause cascade failures [18]. Given the seriousness of the potential impact of our proposed malware, it is essential to be aware of this type of threat before it becomes a real-world problem.

We organized the rest of this paper as follows: Section 2 reviews related work. The methodology is shown in Section 3. Section 4 presents the implementation and analysis of the proposed DCmal-2025, and Section 5 presents the results of our malware detection, which is conducted using the VirusTotal platform. In Section 6, we propose various countermeasures to mitigate the harmful impact of the DCmal-2025 malware, as well as other similar malware. Section 7 examines the ethical and legal considerations for conducting this research. Finally, Section 8 concludes the paper and outlines potential future work.

2. Related Work

Ensuring the security of network services is essential for maintaining reliable and uninterrupted communication. However, these services are increasingly becoming targets for various network-based attacks and malware, which aim to manipulate routing information, disrupt and interrupt services, or violate data confidentiality [19,20]. In this section, we review real-world examples of both attacks and malware that compromise routing services either by exploiting vulnerabilities or by abusing legitimate system functionalities. The objective of this review is not only to highlight the techniques that are used to exploit routing services but also to investigate whether any previous standalone malware has specifically abused the routing table to cause DoS conditions, thereby confirming the novelty of our contribution. We have organized this section into two categories: attacks targeting routing services and advanced malware targeting routing services, presenting them chronologically by the approximate time these attacks and malware first appeared, highlighting the evolution of threats to routing services.

2.1. Attacks Targeting Routing Services

Address Resolution Protocol (ARP) spoofing, also known as ARP poisoning, is one of the earliest known attacks that hackers have used since the 1980s [21]. This attack abuses the normal legitimate behavior of the ARP for malicious purposes. The ARP is a basic network discovery protocol that matches IP addresses, typically an IPv4 address, to MAC addresses within a local area network (LAN) environment [22,23,24]. During this attack, an internal attacker who is already connected to an LAN scans the network to identify the IP addresses of devices, such as the router or other targets. Then, the attacker starts to send forged ARP messages to the victim’s device, claiming that the MAC address of the attacker’s device matches the IP address of the authentic device (e.g., a router). When the victim device (e.g., a computer) receives the forged ARP message, it will immediately accept and store it in its ARP cache without performing any verification. As a result, the data will be redirected to the attacker’s device instead of being sent to the authentic destination device in the network. Thus, an attacker can launch various types of attacks, such as MITM, DoS, or session hijacking [22,25]. As we observe, an ARP spoofing attack works by poisoning the ARP cache on a victim’s device, which leads to redirecting the traffic through the attacker’s device. This forms an indirect manipulation of routing, since the routing table itself remains unchanged. The attack mainly focuses on intercepting the traffic, but in some cases, it can intentionally cause a DoS condition by dropping all of the victim’s traffic.

ICMP redirect attacks are another early threat that affects the routing services. It exploits weaknesses in the Internet Control Message Protocol (ICMP), which is the basic network management tool in the TCP/IP protocol suite that handles error reporting and diagnostics [26]. In this attack, attackers create forged ICMP messages and send them into the network. As a result, they trick network devices into modifying their routing paths to redirect traffic to these attackers [27,28]. These attacks become particularly concerning in Wi-Fi networks, where attackers can easily impersonate legitimate authenticated access points (APs) in the network [27,28,29]. Based on the latest studies [29], ICMP redirection attacks have evolved significantly from their earlier versions. Previously, the attacker had to be located locally on the same network as the victim to eavesdrop on network traffic and write forged messages that appeared legitimate. However, attackers can launch these attacks remotely in a newer and more sophisticated version by exploiting vulnerabilities in stateless protocols such as IPIP, UDP, and GRE [29]. The experimental results in [30] show that 89 % of real-evaluated Wi-Fi networks are at risk of the sophisticated version of ICMP redirect attacks. Furthermore, attackers can exploit the forged ICMP redirect messages to silently send victim device traffic into black holes, resulting in stealthy DoS attacks by an attacker who does not need to be on the same network. Our review indicates that ICMP redirect attacks may sometimes result in a DoS condition, while at other times, they only cause traffic rerouting through the attacker’s device. This attack does not use a standard command to log into the victim’s system and change its routing table. Instead, the change occurs when spoofed ICMP control messages are accepted; then, the victim updates its routing table based on false instructions, which then lead to traffic being redirected through the attacker’s device or silently dropped.

Since the late 1990s, BGP hijacking has become a significant threat to network security. The Border Gateway Protocol (BGP) is a protocol designed to exchange routing information between autonomous systems (ASes) on the Internet [31,32]. It lacks internal validation mechanisms, making it vulnerable to misuse. Any single fault in routing information can affect routing globally and lead to BGP hijacking, as occurred in the 1997 AS 7007 incident [33,34]. There is more than one type of BGP hijacking, including a range of types from accidentally misconfigured routers to malicious hijacking attacks [31,35,36]. Route origin change, also known as route origin hijacking, is one of the most common mechanisms of BGP hijacking. The hijacker (usually an AS) in this mechanism advertises to neighboring ASes its ownership of specific IP prefixes that it does not own. This false advertisement leads the other ASes to update their routing tables incorrectly, causing them to reroute their traffic to the attacker’s network instead of the real network. This kind of attack can be exploited to intercept, reroute, or drop traffic, affecting both service availability and data confidentiality [31,35,37,38]. We note that BGP hijacking represents an indirect form of routing manipulation, since the attacker relies on false advertisements to mislead ASes into updating their routing tables incorrectly. The main purpose of this attack is to reroute or intercept traffic on a large scale, but sometimes it causes a DoS condition.

The OSPF protocol is one of the Interior Gateway Protocols (IGPs), which are utilized in extensive systems such as enterprise networks, universities, and data centers. While OSPF supports authentication mechanisms, its default configuration often uses either no authentication or simple clear-text authentication, which makes it easy for attackers to launch OSPF spoofing. OSPF spoofing is a type of cyberattack that targets routing services. If network security protections are not running, attackers can easily initiate OSPF spoofing and inject the network with incorrect Link-State Advertisements (LSAs). With inaccurate information about the route or network status within the LSAs, the network’s routers will be confused in their decisions, causing incorrect routing. Another weakness in this protocol is the assumption that all participating devices in the network are trustworthy. Therefore, the authenticity of received routing updates is not verified, which opens the door to attacks and allows an attacker to update the routing tables with incorrect information, which will lead to the creation of false adjacencies or unauthorized modification of the network topology [39,40]. In our understanding, OSPF spoofing misleads routers with false LSAs, causing them to update their tables incorrectly. This is an indirect way of manipulating routing information, since attackers do not directly change the routing tables themselves. The disruption from this attack may result in a DoS condition in some cases, but not in all.

One of the fundamental services in computer networks is the Dynamic Host Configuration Protocol (DHCP). The main goal of this protocol is to automatically assign IP addresses and other network parameters (e.g., subnet mask, default gateway, DNS servers) to devices that join the network [41]. Rogue DHCP server and DHCP starvation attacks are examples of common attacks that abuse the DHCP protocol [42]. In a rogue DHCP server attack, the attacker sets up an unauthorized DHCP server on the network to distribute false network settings, such as a fake default gateway, to redirect the victim’s traffic through a device controlled by the attacker, which enables the attacker to intercept, modify, and disrupt the victim’s traffic [41]. However, an attacker in a DHCP starvation attack floods the server with spoofed DHCP requests by using randomized MAC addresses, eventually exhausting the DHCP server’s pool of available IP addresses. Consequently, authorized devices on the network cannot acquire IP addresses, thus preventing them from connecting to the network and creating a DoS condition [43]. Unlike previous protocol-level abuse attacks, the TunnelVision attack (CVE-2024-3661) is a recent attack that takes advantage of vulnerabilities in how some VPN clients handle DHCP Option 121 (Classless Static Routes). This attack targets networks whose users rely on the security provided by the virtual private network (VPN). Carrying out this attack leads to injecting malicious static routes into the victim’s device routing table without proper verification. Consequently, it bypasses the VPN tunnel and forwards some traffic outside the encrypted tunnel, allowing the attacker to intercept or alter the victim’s traffic [42,44]. From our review, a rogue DHCP server attack distributes false network settings, such as a fake default gateway. The victims rely on this false setting to update their routing tables, but the attacker cannot use any standard command to update the victims’ routing table information directly. Regarding a DHCP starvation attack, it indirectly leads to creating a DoS condition. Since this attack focuses on exhausting the server’s pool of available IP addresses, it prevents legitimate devices from connecting to the network. The recent TunnelVision attack abuses DHCP Option 121 and causes the victim’s DHCP client to automatically install malicious static routes, which indirectly results in routing table manipulation, which happens without executing direct system commands. However, its primary goal is to bypass VPN tunnels for traffic interception, not to cause disconnection intentionally and create a DoS condition.

2.2. Malware Targeting Routing Services

In 2007, DNSChanger infected millions of computers and routers worldwide. It is another type of malware that can affect the direction of network traffic by changing the IP address of the DNS server to a malicious one, consequently allowing attackers to control victims’ Internet traffic and perform malicious activity [45,46,47]. Typically, DNSChanger spreads when users access malicious websites, click on malicious links, or open infected files that prompt the malware to download to their computer. Furthermore, DNSChanger malware can gain access to the network by exploiting security holes in the router firmware or by logging in with the unchanged default router credentials that many users forget to change. To dismantle the cybercriminal network behind DNSChanger, the FBI launched `Operation Ghost Click’ in November 2011. They created temporary clean DNS servers, which were still operational until 9 July 2012, to give affected users enough time to clean their devices of DNSChanger malware and restore normal Internet service [45,47]. From our understanding, DNSChanger malware did not directly manipulate the routing table; its core mechanism was to change the victim’s DNS server IP address to a malicious one, which led to the redirection of the victim’s traffic to another malicious server. It can be a first step for a larger attack. While the primary goal was financial gain through traffic redirection, the attack could also cause a Denial-of-Service (DoS) condition, which may occur if the attackers’ DNS servers went offline.

In March 2018, researchers at Kaspersky Lab discovered Slingshot, an advanced malware that had silently infected routers, especially MikroTik models, since at least 2012. The malware targeted organizations and people mainly in Africa and the Middle East for espionage purposes [48]. Slingshot spreads through the infected routers, where it uses the router as an entry point to infect more valuable targets, such as the computers of network administrators. The attacker first attempts to infect the network router and plants a malicious Dynamic Link Library (DLL) file. This DLL acts as a downloader for other malware components and modules. If the administrator uses the infected router management software to configure this router, this software unknowingly downloads and then executes the malicious DLL file on the administrator’s device. As a result, the administrator’s computer becomes infected, and Slingshot starts collecting sensitive data such as passwords and network information. Slingshot then uses AES-encrypted channels to transmit these data back to its Command and Control (C&C) servers, making it difficult to identify this malicious behavior [48,49]. As we observe, Slingshot malware exploited unknown vulnerabilities in MikroTik routers to drop a malicious DLL onto administrator machines. It did not work alone but was part of a larger espionage campaign. Slingshot malware did not manipulate the victim’s routing table or cause a DoS condition, as its primary purpose was data theft and surveillance.

Mirai is a type of malware that mostly targets IoT devices and routers [50]. The first identification of this malware was in August 2016, and it gained significant attention when it was utilized to conduct widespread distributed Denial-of-Service (DDoS) attacks in September 2016. It operates at the network layer without aiming to alter the routing table, and it spreads by scanning the Internet for IoT devices or routers with open Telnet ports, particularly those with unchanged default credentials and weak security settings. Once the malware has compromised the targeted device, it downloads its binary and connects to the attacker’s C&C server to obtain instructions to follow. Therefore, this infected device becomes part of a botnet controlled by the C&C server, which can direct it to launch DDoS attacks. Some of the most significant DDoS attacks recorded have been caused by Mirai, impacting essential websites and services worldwide. Mirai malware can hide its presence, remove any other competing malware, and continuously scan for additional weak devices to spread the infection. Since its original release, it has passed through many versions, each of which has undergone improvements to target new devices and improve its capabilities [50,51]. According to our understanding, Mirai did not exploit a specific software vulnerability, but it relied on weak or unchanged default credentials in IoT devices and routers. This malware was not a standalone incident but a part of a broader campaign to build massive botnets. Regarding the victims’ routing tables, Mirai did not change or update them, where its core mechanism was to conscript devices into a botnet controlled by C&C servers. The primary purpose of Mirai was to launch large-scale DDoS attacks, making service disruption its direct and intentional outcome.

In addition to DNSChanger, the Switcher Trojan is another malware that targets routers by modifying DNS settings. The key difference between them is that DNSChanger infects both computers and routers, while Switcher Trojan uses an infected Android device as a tool to attack Wi-Fi routers. The academic literature on this malware is limited, and the most available details on it come from industry reports or vendor blogs. The Switcher Trojan malware was discovered by Kaspersky Lab researchers in 2016 and usually spreads through malicious apps that mimic known apps [52,53]. Once the user installs this malicious app on his/her Android device, the malware begins collecting information about the connected Wi-Fi network, such as the Basic Service Set Identifier (BSSID) of the network, and it sends this collected information to the attacker’s C&C server. After that, the malware tries to access the router’s admin interface by using the common default login credentials. When it is successfully logged in, it performs DNS hijacking by altering the IP address of the DNS server to that of a malicious DNS server. As a result of the router being infected, fake DNS settings spread to all connected devices of this router, which leads to compromising the complete network [54]. From our analysis, the Switcher Trojan did not exploit a specific software vulnerability; it abused weak or unchanged default credentials on routers. It was not a standalone tool but part of a campaign that spread through malicious Android applications, which often mimicked legitimate apps as a form of social engineering. This malware did not manipulate the routing table directly. Instead, it altered DNS settings on the router to redirect traffic. Its purpose was to intercept traffic through DNS hijacking, not to create a DoS condition.

VPNFilter is a multistage, sophisticated malware publicly reported in May 2018 by Cisco Talos. It targets networking devices, such as routers and network-attached storage (NAS) devices [55,56,57]. The attackers did not rely on any new or unknown vulnerabilities in the targeted devices. Instead, they compromised devices with known flaws, outdated firmware, or weak/default login credentials [57]. VPNFilter operates through a multistage infection process designed to ensure persistence and stealth. There are three stages. The first stage begins when the router is compromised. The malware in this stage does not directly perform malicious actions; instead, it prepares the infected device by locating a malicious server through IP addresses, which are sometimes hidden in the metadata of online stored images. This sophisticated mechanism was created to ensure that malware can survive on the infected device even if the connection to the C&C server is lost or after a reboot. The second stage is the core part of this malware. Through this stage, a temporary module is downloaded from the malicious server. The data from the infected router are collected using the downloaded module, which also communicates with the attacker’s C&C server to obtain and execute instructions on the infected router, exfiltrate data, inspect traffic, and enable the downloading of additional modules. Importantly, malware can manipulate network traffic through iptables rules and packet filtering to redirect it through a malicious server controlled by the attackers. This allows attackers to alter, monitor, or block traffic. In the third and final stage, various optional plug-ins are available to extend the malware’s capabilities and functionality, depending on the attacker’s objective. In some cases, VPNFilter continues to overwrite and alter part of the infected device’s firmware and then restarts it, rendering the device unusable [55,56,57]. After reviewing VPNFilter, we observed that it was a complex, multistage malware targeting routers and NAS systems rather than end-user devices. It did not rely on zero-day vulnerabilities in the targeted devices. Instead, it compromised devices with known flaws or with weak security practices, such as outdated firmware and default credentials. This malware was part of a coordinated campaign rather than a standalone tool. VPNFilter could manipulate the network traffic of infected routers, but only through its Stage 2 modules, which used packet filtering and iptables rules to enable espionage and traffic interception. This malware primarily focuses on data theft and surveillance, but it also has the potential to create a DoS condition. VPNFilter has the ability to overwrite the device firmware, force a restart, and leave the system permanently unusable, which results in a DoS condition. In VPNFilter, both traffic manipulation and DoS served as components of a broader multistage campaign rather than being standalone objectives.

The CTRL team at Cato Networks discovered Ballista, a new IoT botnet malware, in January 2025. This malware exploits a CVE-2023-1389 vulnerability in TP-Link Archer routers, especially the AX21 model. CVE-2023-1389 is a high-severity vulnerability that affects routers running outdated firmware. This malware allows remote code execution by causing command injection. The routers are infected when executing malicious shell scripts to download malware binaries. After infecting the routers, Ballista establishes an encrypted C&C connection on port 82, allowing attackers to have full control of the router. As a result, the attackers can carry out remote instructions, launch DoS/DDoS attacks, or even read and steal sensitive files from the infected device. Another capability of this malware is its self-preservation ability, as it kills previous instances of itself and removes itself from the disk after execution to avoid detection [58]. From our understanding of the Ballista malware, it exploits a known vulnerability in TP-Link Archer routers, making it dependent on outdated firmware rather than social engineering or weak credentials. It is not a standalone but instead is designed to work as part of a botnet campaign. Ballista does not manipulate the victim’s routing tables, where its core work is to establish control over the device through remote code execution. Its primary purpose is to enable remote access and large-scale DoS/DDoS attacks, with self-preservation features to evade detection.

All threats discussed in this section aim to control network traffic by rerouting, intercepting, or disrupting connections. Some of these threats can indirectly cause routing table changes, but this is typically achieved by tricking the victim into updating the routes with false information. For example, this occurs in ICMP Redirects, which rely on spoofed messages, and in the TunnelVision attack, which abuses a specific DHCP option. However, none of these threats directly aim to disconnect targeted devices through standalone malware that modifies routing tables solely by legitimate administrative commands. To highlight this exploitation technique, show its potential impact on systems and networks, and raise awareness among security professionals, this research introduces DCmal-2025. This novel proof-of-concept malware operates independently and disconnects infected devices by directly modifying their routing tables through the misuse of standard routing commands. DCmal-2025 causes an unjustifiable stealth disconnect from the network, without leaving any evidence.

Table 1. Summary of attacks and malware targeting routing services.

Threat Name	Threat Type	Affected Systems	Exploited Component	Primary Objective	Routing Table Manipulation (Directly?)	Attacker Origin
ARP Spoofing	Spoofing Attack	LAN Devices	ARP Protocol	Intercept/Modify traffic	No	Internal
ICMP Redirect	Traffic Redirection Attack	Linux, Mac, Android, FreeBSD	ICMP Protocol	Redirect traffic to the attacker	No	Internal/External
BGP Hijacking	Routing Attack	Routers, AS-level Networks	BGP Protocol	Reroute traffic via malicious AS	No	External
OSPF Spoofing	Routing Attack	Enterprise Routers	OSPF Protocol	Reroute traffic internally	No	Internal
TunnelVision (DHCP)	Network Bypass Attack	LAN Devices (users of VPN)	DHCP Option 121	Divert traffic outside the VPN	No	Internal
DNSChanger	DNS Hijacker Malware	Routers, PCs	DNS Settings	DNS Hijack	No	Internal/External
Slingshot	APT Malware	Routers, Admin PCs	Router Firmware, Management	Espionage/Data Theft	No	Internal/External
Mirai	Botnet Malware	IoT Devices, Routers	Telnet (Weak Credentials)	Launch DDoS Attacks	No	External
Switcher Trojan	DNS Hijacker Malware	Wi-Fi Routers	DNS Settings	DNS Hijack	No	External
VPNFilter	Modular malware	Router, NAS	Routers (Firmware/Settings)	Divert traffic for data theft/Hijack traffic	No	External
Ballista	Botnet Malware	IoT Routers (TP-Link)	CVE-2023-1389 (RCE)	Launch DDoS Attacks/Steal Files	No	External
DCmal-2025	Standalone Malware	Windows and Linux Devices	Routing table	Disconnect system	Yes	Internal/External

provides an overview of the threats discussed previously and compares them with the contribution of this work.

3. Methodology

Figure 1 presents the structured methodology that we followed to design, implement, and validate the proposed DCmal-2025 malware. The primary objective of this study is not to introduce a new threat but to provide a proof of concept that can be utilized to enhance defensive models.

Our methodology includes different phases. We began with a vulnerability investigation phase to examine the existing attacks and malware that target routing services. This step helped us understand how attackers exploit routing services. In this review, we found no evidence of previous standalone malware designed to disconnect targeted devices by abusing standard commands and modifying the routing table. Building on this gap, we proposed the novel PoC DCmal-2025 malware, which causes a DoS condition by altering the routing tables of infected devices.

As shown in the second phase of our methodology, we developed two types of malware, each written in the C and Rust programming languages. As we will explain in the following sections, Type 2 of our malware is more sophisticated than Type 1. Moreover, we conclude that the programming language used in the development of malware plays a crucial role in determining the detection rate.

In Phase 3, we executed all samples of the proposed malware in controlled environments on both Windows and Linux systems. During these experiments, we observed that malware successfully affected network connectivity on both systems, as expected. We uploaded all variants of the DCmal-2025 malware to the VirusTotal platform in Phase 4 to evaluate the effectiveness of different antivirus engines in detecting these samples. After that, we compared the results of the VirusTotal scan across various types, programming languages, and operating systems.

To make it easier for readers to understand the real impact and risk of DCmal-2025, we applied it in a case study of an educational environment in Phase 5. We chose this environment because it is one of the institutions that is highly dependent on continuous connectivity, it provides a realistic but isolated environment for safe experimentation, and its infrastructure information is easier to obtain compared to other contexts. These factors make the chosen educational context a suitable example to highlight the risk posed by our proposed malware. We note that this case study was conducted to demonstrate feasibility and illustrate the potential impact of different variants of DCmal-2025 in a controlled environment, rather than to generalize to all possible environments. Broader testing in diverse network contexts is identified as part of our future work.

Finally, in Phase 6, we propose possible countermeasures that can be applied to prevent infection by the proposed malware and enhance its detection capabilities. The following sections provide a comprehensive and detailed description of each phase of this methodology.

4. Proposed DCmal-2025 Implementation, Execution, and Impact Assessment

Every modern operating system that supports network connectivity must have a routing table. The routing table is a critical data structure in a router or a network host device that contains a list of possible destination routes within the network. The routing table dictates how packets are sent from the local device to their intended destinations across the Internet or network [13,14]. The unauthenticated routing table modification can seriously impact network performance, stability, and security. If attackers can successfully alter one or more entries in the victim device’s routing table, they can redirect the victim device’s network traffic to a malicious node. This redirection enables the attackers to launch man-in-the-middle (MITM) attacks and DoS attacks or carry out other malicious activities [59,60].

When studying threats that target the routing table, we observed that most modifications were carried out as part of broader attack strategies through system-level vulnerabilities, remote control mechanisms, or malware integrated into a more sophisticated package. However, there is a clear gap in research on standalone malware that directly targets and manipulates the routing table to cause DoS conditions without being on auxiliary attack components. Currently, no publicly documented standalone malware achieves a DoS condition through direct manipulation of the routing table without being integrated with other attacks or serving as a component of a larger threat. To fill this gap and help defenders in their battle against attackers, we designed and implemented the DCmal-2025 malware. This malware is a novel standalone malware that operates independently and is not derived from or related to any existing attack or malware family. The primary purpose of DCmal-2025 is to modify the routing table to create DoS conditions directly. It achieves this without using advanced tools or AI techniques; it only exploits and abuses normal administrative privileges.

The following subsections describe the development process of the DCmal-2025 malware, explain in detail how it operates, present a structured analysis through MITRE ATT&CK mapping, and evaluate its impact on network functionality across multiple platforms.

4.1. Malware Development

The DCmal-2025 malware development process involved iterative phases to improve its performance and portability. The initial phase transformed our basic idea into a proof of concept (PoC) written in C, aiming to verify whether it is technically possible to manipulate the routing table and cause a DoS condition. After validating the concept, we improved the PoC by adding more advanced features, such as time-triggered execution and automatic connection restoration after a specific time. As a result of these phases, we implemented two distinct types of our malware. One is more advanced than the other, but both can work and affect the network connection. These two types are the following:

• Type 1: DCmal-2025-T1 (Immediate Execution): This is the simplest type of malware, which is initiated when the user unknowingly executes the malware file, disguised as a legitimate program, through a social engineering technique. Upon execution, the malware requests administrative privileges (administrator in Windows or root in Linux) if they are not already granted before it can access and modify the routing table. Then, it immediately disconnects the device’s connection without restoring it. Algorithm 1 illustrates the pseudocode of this type.

Algorithm 1: Pseudocode of the DCmal-2025-T1 Malware

1: Check/Request Administrator Privileges ▹ Social engineering prompt if privileges are not already granted 2: Access Routing Table            ▹ Open system routing entries for possible modification 3: Disrupt Connectivity        ▹ Modify selected routing entries to block/drop all network traffic 4: Save and Apply Changes          ▹Save changes so the disruption takes effect immediately 5: Exit         ▹ No auto-restore is performed; connectivity remains down until user intervention

• Type 2: DCmal-2025-T2 (Time-Triggered Execution with Restoration): We developed this type after several enhancements to Type 1. Like Type 1, this variant relies on social engineering to gain admin privileges. Once privileges are granted, the malware operates silently in the background. This type does not act immediately, but it waits until the infected device’s system clock matches a scheduled date and time (e.g., 1 January 2026, at 1:31 a.m.). At that point, the connection is disconnected. After a predefined time (e.g., 2 min), the malware automatically restores the connection. This design simulates a temporary and stealthy DoS event, showing how time-based evasion can be used. The Algorithm 2 illustrates its pseudocode.

Algorithm 2: Pseudocode of the DCmal-2025-T2 Malware

1: Check/Request Administrator Privileges▹ Social engineering prompt if privileges are not already granted 2: Start Loop            ▹ The malware continuously checks for the predefined trigger time 3: if predefined time is reached then 4:   Access Routing Table            ▹ Open the system’s routing table for modification 5:   Disrupt Connectivity          ▹ Modify routing entries to block/drop all network traffic 6:   Start Restoration Timer          ▹ Set a delay after which connectivity will be restored 7:   Reconnect Network Connectivity        ▹ Restore the original routing table after the delay 8: end if 9: End Loop

These two types of DCmal-2025, instant or autonomous, provide an elastic attack time that can be coordinated with a planned malware campaign targeting critical network services in various sectors.

The DCmal-2025 malware was later translated into the Rust programming language to harden both types and make them more challenging to detect using conventional antivirus techniques. The results showed that the Rust-based version was more successful than the C version in passing the antivirus tests; this is discussed in detail in later sections. Figure 2 illustrates the development process from idea formulation to final impact reporting.

MITRE ATT&CK Technique Mapping

To better explain the relationship between our DCmal-2025 malware and real-world attack techniques and to ensure that it mimics real malware, we mapped its malicious behavior with the MITRE ATT&CK framework. MITRE Corporation presents the ATT&CK framework, a publicly available knowledge base used by cybersecurity professionals to document attacker tactics, techniques, and procedures (TTPs). Defenders commonly use this framework to identify the tactics that hackers employ, compare threats, guide red teams during security tests, and determine the tools or logs an organization needs to protect itself better [61]. By conducting this mapping, we aim to help other researchers better understand the attack process of our malware, enabling them to improve their ability to prevent the risks posed by such malware.

Upon reviewing our proposed types of the DCmal-2025 malware, we observe that both types map to several techniques in the MITRE ATT&CK framework. They rely on their work on well-known techniques commonly used in malware creation, such as social engineering, privilege escalation, and network manipulation. Moreover, Type 2 is more advanced than Type 1, as it includes an additional time-triggered technique that delays the execution of network disconnection and recovers connectivity after a predefined delay, without notifying the user.

Table 2. Mapping of the DCmal-2025 malware types to MITRE ATT&CK techniques.

Malware Type	ATT&CK ID	ATT&CK Technique Name	Behavior by Malware Type
DCmal-2025-T1	T1204.002	User Execution: Malicious File	Uses social engineering to trick the user into running the executable file.
	T1548	Abuse Elevation Control Mechanism	Uses social engineering to request admin privileges from the user.
	T1562.004	Impair Defenses: Disable or Modify Network Configurations	Alters the routing table, disconnecting the device.
DCmal-2025-T2	T1204.002	User Execution: Malicious File	Same as DCmal-2025-T1
	T1548	Abuse Elevation Control Mechanism	Same as DCmal-2025-T1
	T1053.005	Scheduled Task/Job: Scheduled Task	Waits until a predefined time before disconnecting the network.
	T1562.004	Impair Defenses: Disable or Modify Network Configurations	Alters the routing table at the scheduled time, disconnecting the device, and then restores it after a delay.

summarizes MITRE ATT&CK techniques used by each type of our DCmal-2025 malware.

4.2. DCmal-2025 Impact

The two types of DCmal-2025 malware were tested on both Linux and Windows systems to confirm their ability to directly modify the routing table and impact network connectivity. All experiments were conducted in a controlled and isolated virtual environment to prevent unwanted effects and malicious actions, such as disconnecting the host machine from the network. We used VirtualBox to deploy several virtual machines running Windows and Linux. We also utilized GNS3 to emulate the network topology of these different virtual machines. This configuration mimics the behavior of a real-world system while preserving complete control for experimental purposes.

The DCmal-2025 malware has successfully demonstrated its ability to alter some critical routing entries on both Windows and Linux platforms, thus preventing targeted devices from accessing their network without exploiting any vulnerabilities or depending on any other external payloads. This DoS condition was verified by applying ping tests to known IP addresses (such as ping 8.8.8.8) before and after the DCmal-2025 malware’s execution. The following subsections describe how both malware types behave on Windows and Linux systems, supported by technical details and screenshots.

4.2.1. Impact of the DCmal-2025-T1 Malware

To assess the impact of the DCmal-2025-T1 malware on system connectivity, we conducted a ping test on both Windows and Linux operating systems before and after executing this type of malware and captured a screenshot of the results. The first ping test showed that the device is connected to the network. Once Type 1 of our malware is run, the device’s network connection is immediately disconnected. Thus, the second ping test showed a loss of connectivity. The results confirm that the proposed malware successfully disrupted network connectivity. The C- and Rust-based implementations of DCmal-2025-T1 exhibited the same behavior on both platforms. Figure 3 illustrates the results captured before and after the execution of DCmal-2025-T1 (a) from the Windows system and (b) from the Linux system.

4.2.2. Impact of the DCmal-2025-T2 Malware

Figure 4 and Figure 5 present screenshots of the connectivity status of the victim device before and after executing the DCmal-2025-T2 malware on both Windows and Linux platforms. As mentioned above, this type is designed as a time-triggered malware with automatic restoration, where it disconnects the device from the network only once at a predefined time and date. Then, the connection is restored after a scheduled period.

To demonstrate the impact of DCmal-2025-T2, we captured the ping results in several cases: before and after it was run, at a predefined time and date, and after the connection was restored. In Figure 4, the screenshots were captured from the Windows platform, while the screenshots in Figure 5 were captured from the Linux platform. In Figure 4a, the ping was successful until 1:31 a.m. on that day, which was a predetermined time for this experiment, and it can easily be adjusted to any other time. After that, ping requests failed for a short period. The screenshot in Figure 4b shows how our malware successfully restores the connection without the user noticing, where the ping test becomes successful after 30 s, a scheduled period that can also be changed to simulate different scenarios. On the other hand, the Linux platform exhibited the same behavior. As shown in the screenshot in Figure 5a, the ping was successful until 20:20 on that day, which is also configurable as in the Windows scenario. After that, ping requests failed for a short period, and the screenshot in Figure 5b illustrates how the DCmal-2025-T2 malware restores the connection.

4.2.3. Systematic Measurement of Service Degradation

After presenting the ping screenshots that verified connectivity loss, this section analyzes measurable metrics to provide a systematic assessment of service degradation caused by the variants of DCmal-2025. These metrics are the following:

• Downtime (DT): This metric measures the duration between the last successful reply ($t_{last\_Sreply}$) and the first successful restored reply ($t_{first\_Rreply}$). DT can be calculated using Equation (1).

  $$DT=\left(t_{first\_Rreply}\right)-\left(t_{last\_Sreply}\right)$$

  (1)
  The downtime of DCmal-2025-T1 is more complex to define because it lacks an automatic restoration mechanism. In this type, the connection is restored only when the user notices the disconnection, identifies the reason behind it, and then manually reconnects. It is challenging to locate the reason if they are not aware of DCmal-2025, especially since there is no ISP-related reason behind it. In contrast, the downtime for DCmal-2025-T2 is easily measurable, since the malware automatically restores the connection after a predefined time, which represents the DT here.
• Packet Loss Rate (PLR):This is the percentage of data packets that fail to reach their destination. Let $P_{lost}$ be the number of packets lost and $P_{sent}$ the total number of packets sent. Accordingly, the PLR can be calculated using Equation (2).

  $$PLR=\left({\displaystyle \frac{P_{lost}}{P_{sent}}}\right)\times 100\%$$

  (2)
  The PLR metric can be derived directly from the ping screenshots. For example, in the Windows ping screenshots, the ping output showed 0% packet loss before executing the DCmal-2025 while the device was connected and functioning normally. Once the malware was executed, either DCmal-2025-T1 or DCmal-2025-T2, the packet loss immediately rose to 100%, meaning that all packets were blocked or dropped, resulting in a complete loss of communication.
• Time to Recovery (TTR): This metric captures the delay between the restoration time ($t_{Restore}$) and the first successful restored reply ($t_{first\_Rreply}$). The formal definition of the TTR is given in Equation (3).

  $$TTR=\left(t_{first\_Rreply}\right)-\left(t_{Restore}\right)$$

  (3)
  There is a clear distinction between DT and TTR. DT represents the entire outage period, while TTR refers only to the recovery delay. Our proposed DCmal-2025 malware is a very simple malware that relies only on misusing legitimate commands. It does not rely on complex modules or session re-establishment. Therefore, once restoration is triggered, whether manually in Type 1 or automatically in Type 2, the recovery is instant, with no additional recovery or wake-up period. This real-time behavior was observed in our experiments. The instant recovery can be considered one of the stealth advantages of our design, as it reduces the likelihood of being detected by administrators.

5. DCmal-2025 Analysis Using VirusTotal

To understand the behavior of malware and its impact on different systems, researchers and cybersecurity experts perform a crucial stage known as malware analysis in their work. They gain valuable knowledge from this process, which helps them design effective defense and detection strategies, as well as to develop effective countermeasures. The VirusTotal platform [62] is one of the most widely used platforms that can be utilized in malware analysis. Using this platform, researchers and experts can conduct multi-engine scanning of submitted samples, working with more than 70 antivirus engines. Additionally, it provides static feature extraction and offers dynamic behavioral observation through several integrated sandboxing environments. Thus, VirusTotal is a valuable publicly available platform that can collectively indicate if the submitted sample is malicious, potentially malicious, or benign.

In our research, we submitted both types of the proposed DCmal-2025 malware to VirusTotal to evaluate whether current security tools could detect and recognize it. We documented the results of the antivirus scans to help system defenders become aware of this type of malware. In addition, we reviewed the reports from six VirusTotal sandboxes (C2AE, CAPE, Microsoft Synt, Jujubox, Zenbox). None of them flagged the malware as malicious, which is consistent with its simplicity. DCmal-2025 does not generate suspicious traffic, establish remote control, or leave behind any malicious files; instead, it executes only legitimate routing commands. As a result, while VirusTotal provides valuable insights, conventional sandboxing does not capture the actual disruptive impact of our malware. Therefore, in this section, we focus on the static detection results from VirusTotal. The following subsection explains how the analysis was performed for both DCmal-2025-T1 and DCmal-2025-T2.

5.1. Detection of the DCmal-2025-T1 Malware via VirusTotal

The analysis was carried out for DCmal-2025-T1 by uploading its source code and the corresponding executable files for Linux and Windows to the VirusTotal platform. Initially, we uploaded the files for this type, which were developed using the C programming language. According to the screenshots in Figure 6 and Figure 7, the scanning results at the source code level for both Windows and Linux platforms showed that the source code was not flagged as malicious by any of the antivirus engines. These results are likely due to our proposed malware containing standard commands commonly used in legitimate operations and not matching any known threat signatures. Similarly, the ELF executable file for the Linux system was not flagged as malicious; a complete justification for these results is provided in Section 5.3.

However, the executable file (C-based) for the Windows system was detected as malicious by 5 out of 71 antivirus engines, corresponding to an approximate detection rate of 7.04%. These five antivirus engines were CrowdStrike Falcon, SecureAge, Symantec, Bkav Pro, and MaxSecure. CrowdStrike Falcon, SecureAge, and Symantec are enterprise-level antivirus solutions used by large organizations, including enterprises, banks, and government systems [63,64,65]. Bkav Pro antivirus serves a broad user base, from home users to large enterprises. It offers various editions, including Home, SME Endpoint, and Enterprise Endpoint, and it is popular in the Vietnamese business antivirus market [66]. On the other hand, MaxSecure is generally used in consumer or small business environments for Windows, macOS, Android, and iOS systems [67,68].

We observed a common characteristic among these five antivirus engines: they were all based on heuristic analysis or artificial intelligence, rather than traditional signature-based detection techniques. The Symantec engine displayed the alert “ML.Attribute.High confidence”, indicating that the sample was flagged by machine learning, which is most likely based on a previous learning pattern from a well-known sample. CrowdStrike displayed the alert “Win/malicious_confidence_60%”, meaning that the statistical analysis of the sample’s features resulted in a malicious confidence score of 60%. For the SecureAge engine, the sample was flagged generically as “Malicious” using a multi-engine AI-based approach without providing any additional details. MaxSecure and Bkav Pro displayed generic alerts labeled as “Trojan. Malware. 300983. Susgen” and“W64.AIDetectMalware”. These two labels are general and appear to be based only on the abnormal behavior observed in the sample, where the engines did not indicate any specific malware family or provide a detailed classification on the label. However, all previous alerts can be considered general and lack detailed explanations, which could increase the likelihood of false positives in the detection process.

According to the scanning results, 66 out of 71 antivirus engines reported the file as undetected, suggesting that they found no signs of known malicious behavior in the uploaded file. Upon closer examination, we observed that while some antivirus software flagged our proposed malware, many others, especially those used on regular personal computers or those based primarily on signature-based detection, did not. Examples of the antivirus engines that failed to detect our malware include well-known and standard consumer-grade antivirus software, such as Microsoft Defender, Kaspersky, and McAfee [69]. The fact that some enterprise-level antivirus tools detected DCmal-2025-T1 shows that it poses real risks, even if it appears benign and clean to more basic or consumer-grade solutions. These findings underscore a critical point that our proposed malware has the potential to bypass a wide range of antivirus engines, particularly those that rely primarily on signature-based detection or expect a well-known threat pattern.

To reduce the detection rate of our DCmal-2025-T1, we employed an evasion tactic by translating the source code implementation from C to Rust and compiling it into an executable file. After that, we uploaded the Rust source code and the resulting executable file to VirusTotal for analysis. As shown in Figure 8, the number of antivirus engines that detected the Rust-based Windows executable file was only 1 out of 72, which is notably lower than the number that detected the equivalent C-based executable, 5 out of 71, as previously shown in Figure 6. This corresponds to a reduction in the detection rate from approximately 7.04% to 1.39%. This result indicates that the Rust version was more successful in evading antivirus detection. The new Windows Executable File (Rust-based) is flagged only by the Deep Instinct engine. It is an advanced engine that relies on deep learning techniques, unlike traditional signature-based antivirus engines. Further discussion of this result will be presented in Section 5.3.

5.2. Detection of the DCmal-2025-T2 Malware via VirusTotal

As we mentioned before, DCmal-2025-T2 is more advanced than DCmal-2025-T1. Type 2 includes a scheduled execution to activate the DoS action, in addition to automatically restoring the network connection after a predefined restoration time. We followed the same procedure as with Type 1, where we uploaded the DCmal-2025-T2 source code and the corresponding executable files for Linux and Windows to the VirusTotal platform. We started with the files developed using the C programming language. Then, we uploaded the developed files using the Rust programming language to check whether changing the programming language would reduce the detection rate of this type of malware, as it had in Type 1. The screenshots in Figure 9 and Figure 10 show that only the scanning result of the Windows executable file (C-based) for the DCmal-2025-T2 was detected as malicious by 7 out of 72 antivirus engines, corresponding to an approximate detection rate of 9.72%. In contrast, the scanning results for both the Windows and Linux source code, as well as the Linux executable file (all of which are C-based), were not flagged as malicious. Our justification for these results is consistent with that of Type 1, where Type 2 of our proposed malware does not match any known threat signatures and contains standard instructions commonly used in legitimate operations. We discuss these scan results in more detail in Section 5.3.

Regarding the scanning results of the Windows executable file (C-based), the antivirus engines that detected it as malicious were Bkav Pro, Google, Ikarus, MaxSecure, SecureAge, Skyhigh (SWG), and Symantec. As with Type 1, SecureAge, Symantec, Bkav Pro, and MaxSecure continued to classify the files as malicious, displaying the same alerts. However, Google, Ikarus, and Skyhigh (SWG) are three additional engines that flagged the files as malicious in Type 2, resulting in an increase in the detection rate of this type compared to Type 1. The Ikarus engine displayed the alert “Trojan.Win64.Injector,” indicating that it classifies the Type 2 malware as an injector, which means that the file uses code injection to carry out malicious activity without being detected. The alert “BehavesLike.Win64.Dropper.lm” is displayed by the Skyhigh (SWG) engine. This alert indicates that the engine has classified the file as a dropper, a type of malware that installs or delivers other malicious files. Referring to Google’s antivirus engine, it simply flagged the file with the generic label “Detected,” which means that it identifies suspicious traits without linking them to a known malware family or providing more detailed information about it. However, based on our implementation, it is neither a dropper nor an injector. We only added a time-delay mechanism before the main malicious execution in Type 2. After a while, we recover the connection, which is similar to some evasion techniques in real-world malware. This behavior may have led to it being perceived as a threat, causing Ikarus to flag it as an injector, Skyhigh to classify it as a dropper, and Google to classify it as malicious, as indicated by the “Detected” alert.

To assess whether changing the programming language would affect detection, as observed in Type 1, we reimplemented the Windows and Linux source codes of our DCmal-2025-T2 in the Rust programming language and compiled them into executable files. We then uploaded both the source and executable files to VirusTotal. Figure 11 displays the screenshots of the results, showing that only three antivirus engines—Deep Instinct, Elastic, and Rising—flagged the Rust-based version as malicious. These 3 out of 72 engines correspond to a detection rate of approximately 4.17%, which is lower than the detection rate of the equivalent file developed in C, which was approximately 9.72%. This result, similar to that for Type 1, indicates that the Rust implementation was more successful in evading antivirus detection.

5.3. Discussion of the VirusTotal Scan Results

The static analysis using the VirusTotal platform’s results for both types of the DCmal-2025 malware (Type 1 and Type 2) showed apparent differences in antivirus detection rates across file types, platforms, and programming languages used. In both types, the source code files, whether written in C or Rust, were not flagged by any antivirus engines. We previously justified this by noting that the code contains standard system commands used for regular system operation and does not match any known malware signatures. These results highlight the limitations of static analysis when applied to source code, particularly in cases where malware attempts to misuse legitimate operations.

A significant difference was observed in the way antivirus engines responded to executable files on different platforms. The Linux ELF binaries for both types were not flagged as malicious by any of the antivirus engines, whereas several antivirus engines detected the Windows.exe executables as malicious. The absence of detection for Linux executables can be explained based on recent research findings in Linux security. Raffa et al. [70] demonstrated that Linux antivirus engines depend on outdated signature databases and detection regressions, resulting in reduced effectiveness in identifying new threats. This stands in contrast to the Windows environment, where antivirus solutions are generally more mature, more frequently updated, and prioritized by several vendors, mainly because Windows remains the primary target for malware more than other open-source operating systems, such as Linux.

For Type 1 of our malware, the Windows executable file (C-based) was detected by 5 out of 71 antivirus engines, while the Windows executable file (C-based) in Type 2 was detected by 7 out of 72. As we previously discussed, the increase in the detection rate (from 7.04% to 9.72%) was likely due to the inclusion of time-triggered execution logic in Type 2. This execution logic may have caused the antivirus to detect malware by recognizing unusual or suspicious activity patterns, even without any signature match. Despite this increase in detection rate, both values remain relatively low, as only a few antivirus engines successfully classify the files as malicious, while most fail in both types. Moreover, we observed that the detections mostly came from enterprise-oriented antivirus solutions, including CrowdStrike, Symantec, SecureAge, and Skyhigh. On the other hand, the popular and widely used consumer antivirus solutions, including Microsoft Defender, Kaspersky, and McAfee, did not detect either type of malware. This finding underscores the strong possibility that our malware could successfully run on most personal or small business environments without being detected.

We reduced the detection rate of our malware’s Windows executable file for both types by switching from C to Rust as the programming language. The detection rate dropped in Type 1, from 7.04% (C-based) to 1.39% (Rust-based), and in Type 2, it dropped from 9.72% (C-based) to 4.17% (Rust-based). This decrease in detection rate is likely due to the structural differences in Rust binaries. According to recent authoritative research on Rust-based malware [71,72], this reduction in detection rate can be explained by several factors. First, many current antivirus tools have limitations when it comes to analyzing Rust’s compiled structure. In addition, the strong safety features of Rust and its higher-level abstractions make its code more complex and more challenging to reverse engineer. Furthermore, Rust binaries are typically large and statically linked, meaning that they include everything within a single file, making it harder for antivirus tools to scan or correctly identify what the program does, thereby reducing their chances of recognizing malicious behavior. This was observed in our results, where the Windows executable file (C-based) was approximately 13.50 KB in Type 1 and 14 KB in Type 2. In contrast, the Rust-based equivalent files were significantly larger; the Type 1 Rust file was approximately 150 KB, which is roughly 1.011% larger than its (C-based) equivalent. Similarly, the Type 2 Rust file was approximately 249.5 KB, making it around 1.682% larger than the equivalent (C-based) version. We want to highlight that our Rust vs. C results are preliminary observations. They reinforce our main argument about the risk posed by the DCmal-2025 malware but are not intended as a complete comparative study between these two programming languages.

Regarding the type of antivirus that detected Windows executable files (Rust-based), Type 1 of our malware was detected only by Deep Instinct. On the other hand, Deep Instinct, Elastic, and Rising Deep detected Type 2. These antivirus engines differ from those that identified the C-based files, as they rely on more advanced techniques, especially the Deep Instinct and Elastic engines. Deep Instinct depends on deep learning models to detect and prevent even novel threats with minimal impact on performance and training, offering proactive malware prevention [73]. Elastic integration combines endpoint detection and response (EDR) with behavioral analytics to identify potential threats across various systems [74]. Rising Antivirus is a Chinese security solution with limited public documentation on advanced ML capabilities [75]. Another point that we want to emphasize is that both types of malware were developed without using encryption, packing, or other standard obfuscation methods. This finding demonstrates how the misuse of legitimate operations can compromise the system and how our malware, particularly the Rust version, was able to bypass most antivirus tools.

5.4. Case Study of DCmal-2025 on an Educational Network

To enhance understanding of the impact of the DCmal-2025 malware and demonstrate its behavior in a realistic environment, we simulated an educational environment to create a complete malware infection scenario. The aim of executing our malware in this comprehensive setup, not just within a single virtual machine, was to capture the full range of behaviors and effects it might exhibit when interacting with more complex systems. Therefore, it helps develop more robust security measures and effective countermeasures for such malware.

Figure 12 illustrates the complete topology of the simulated educational environment. Through this environment, both types of our DCmal-2025 malware were executed on virtual machines running Windows and Linux systems and hosted on VirtualBox 7.0.22. GNS3 2.2.53 network emulation was utilized to simulate the networks between these virtual machines. We used GNS3 and VirtualBox to ensure that the analysis was performed in a secure and isolated environment, thereby eliminating any risk or harm to our host system. This simulation was conducted on a device equipped with an Intel Core i7-10510U series 1.80 GHz 4-core CPU, 16 GB of memory, and a 477 GB SSD. Windows 11 Home (64-bit) was utilized as the operating system on the host computer.

As shown in the previous Figure 12, the topology simulates a realistic educational network consisting of multiple routers (R1, R2, R3), Layer 2 switches (IOU1–IOU5), a Layer 3 switch (IOU6), a pfSense firewall, and several end devices, including Windows 10 hosts, Ubuntu machines, and Virtual PC Simulator (VPCS) clients. The following is an overview of the key devices and their roles within our suggested topology.

• R1—Main Gateway Router: R1 is a Cisco edge router for the educational network. It connects the network to the simulated external Internet and acts as the primary gateway for all inbound and outbound traffic. With two interfaces, one facing the Internet Service Provider (ISP) and the other connected to the internal pfSense firewall, R1 is responsible for routing all traffic between the educational network and external destinations.
• pfSense Firewall: A pfSense Firewall is located between R1 and R3 (the internal core router). It has two network interfaces (em0 and em1); em0 was configured as a WAN interface and connected to the R1 network, while em1 was configured as an LAN interface and connected to the core router R3 on the internal side of the network. All traffic between the R3 network and the Internet must pass through this firewall, which enforces security policies and filters network traffic between internal subnets and the outside.
• R3—Core Router: R3 in our proposed topology is a Cisco router with multiple interfaces connecting several internal subnets. It acts as the core router of the educational network. Thus, it serves as the default gateway for the connected internal subnets; for example, one interface on R3 is 10.100.2.1 for the 10.100.2.0/24 subnet, another interface is 10.100.3.1 for the 10.100.3.0/24 subnet, and so on. R3 enables inter-subnet routing among all internal LAN segments and provides a single routing point to reach the pfSense firewall, which, in turn, allows access to the Internet. Each subnet represented in the topology corresponds to a separate part of the educational environment, such as student labs, administrative offices, or research areas. The internal parts consist of several end devices, including Windows 10 hosts, Ubuntu machines, and VPCS clients. All of these devices are distributed across different switches (IOU1 to IOU6) to simulate departmental segmentation within the simulated network.
• Layer-2 Switches (IOU1–IOU5): IOU1–IOU5 are five instances of Cisco IOU (IOS on Unix) Layer 2 switches within the internal network. Each one of these switches connects to multiple endpoint devices with a single IP subnet. As an example from our setup, IOU1 connects to the endpoint devices in the 10.100.2.0/24 subnet (such as PC1 at 10.100.2.11 and Win10-1 at 10.100.2.12). In addition, it connects to R3, which serves as the default gateway (10.100.2.1) for the internal network. Similarly, the switches IOU2, IOU3, IOU4, and IOU5 connect hosts in subnets 10.100.3.0/24, 10.100.4.0/24, 10.100.5.0/24, and 10.100.6.0/24, respectively. The IOU1–IOU5 switches operate only on the data link layer (Layer 2), which means the MAC addresses are used to forward traffic within the same subnet. However, if any device sends data to another device located in a different subnet, R3 is utilized to route this traffic through it.
• Layer-3 Switch IOU6: Layer 3 switches, unlike their Layer 2 images, can both switch and route data. In our setup, IOU6 is a Layer 3 switch connected to three different subnets: 10.100.7.0/24, 10.100.8.0/24, and 10.100.9.0/24. It routes traffic between these subnets using its Layer 3 routing capabilities based on IP addresses. However, for communication within the same subnet, it functions as a Layer 2 switch, forwarding traffic based on MAC addresses. To keep the topology simple and focus on routing, we have included only one endpoint device for the 10.100.8.0/24 and 10.100.9.0/24 subnets, although a /24 subnet can support up to 256 hosts.
• Endpoint Devices (VPCs, Windows, Linux): The proposed network topology includes a range of endpoint nodes across different subnets, which are the following:

  -

  VPCS: Labeled from PC1 to PC7 in the Figure 12, these nodes were implemented in the topology to represent lightweight endpoint devices. They can send and receive the network traffic using a simple ping command, which is ideal for testing IP connectivity. They are not whole operating systems such as Windows or Linux, which helps reduce resource usage during simulations.

  -

  Windows 10 Operating System: These devices are labeled in a topology as Win10-1, Win10-2-1, Win10-2-1, Win10-3-1, Win10-4-1, and Win10-5-1. All Windows devices are located internally within the educational network, except Win10-5-1, which is located on the external network. These nodes were implemented to represent endpoint devices that act as either victims or attackers. Any of these devices could become a victim if the user of that device receives and executes the malware executable file. As a result, this device will be infected by our malware and will be disconnected from the network. On the other hand, we assumed that an attacker could control some of these devices and use them to spread malware to other devices across the network. In our network topology, the attacker is considered an external attacker if they used Win10-5-1 to spread the malware. In contrast, they are considered an internal attacker if they used another Windows device located within the educational network to spread the malware.

  -

  Linux Operating System: The educational network topology uses two Linux operating systems: Kali Linux and Ubuntu. A Kali Linux instance is placed in the external network, simulating an external attacker who sends malware from outside the educational network to internal victim devices. Inside the internal educational network, there are two Ubuntu instances, Ubuntu-1-1 and Ubuntu-2-1. These Ubuntu machines can act as victims if they are infected with malware, or they can become internal attackers, spreading the malware throughout the internal network.

• R2—External Router: R2 is another Cisco router in our topology. It is connected to the ISP on one side and to an external 10.200.x.x subnet on the other side. This router is used in the topology to simulate an external network that is located outside the educational network. This external network may be external organizations, remote offices, or even potential attackers. Devices such as KaliLinux-1 (10.200.0.2) and Win10-5-1 (10.200.10.2) are connected to this external subnet to represent external sources of traffic communicating with the educational network.

5.4.1. Performance Analysis

To evaluate the performance and effectiveness of our DCmal-2025 malware on the educational network, we proposed different attack scenarios as follows:

• Scenarios based on the attacker’s location:

  -

  External attacker: When the attacker exists outside the educational network, it is considered an external attacker. In this case, to send our malware file to one of the internal devices within the proposed educational network, it should first pass through the pfSense firewall, which tests and filters the incoming traffic. If the firewall does not block this file, it will successfully reach the target internal device within the network. In the proposed educational network, the devices labeled Win10-5-1 and Kali Linux-1 could act as external attackers. Figure 13 shows an external attacker scenario in our simulated educational network.

  -

  Internal attacker: Unlike an external attacker, an internal attacker could be a device located within the target network, as shown in Figure 14. Any device connected through Layer 2 or Layer 3 switches within our simulated network can be considered an internal attacker if it is under the control of an attacker. The internal attacker has direct access to other internal devices, making it easier for the malware to spread than for the external attacker.

• Scenarios based on the location of the victim:

  -

  Victim connected to a Layer 2 switch: As we mentioned earlier, any device connected to the Layer 2 switch depends on the core router (R3) to communicate with other subnets, and it uses the IP addresses to determine the destination device. However, if this device needs to communicate with another device located within the same subnet, it only uses the MAC address. The execution of our proposed malware on a single device connected to the Layer 2 switch will result in the loss of its inter-subnet connectivity due to the manipulation of its routing table. In contrast, its connection within its local subnet will not be affected, as it depends on MAC addresses. This single-device compromise can have a hierarchical impact across the network, where the isolation of this device will cause the isolation of all its dependent devices. This means that internal services and applications within the affected subnet can still communicate with each other locally but will not be able to access a different subnet or an external network. This demonstrates that compromising just one device with our malware can create a cascading problem that impacts the entire network. Figure 15 shows the impact of the proposed malware on the connectivity of Windows 10-1 and Ubuntu 1-1 machines. Due to the malware’s modification of the routing table, Windows 10-1 lost connection to the core router (R3), which is responsible for connecting Windows 10-1 with other subnets, while the local connection within the same subnet with the PC1 machine (10.100.2.11) remained unaffected. Similarly, Ubuntu 1-1 lost connectivity to other subnets while maintaining connectivity within the same subnet with the machine PC2 (10.100.3.11). It is important to note that the disruption does not stop with the infected device alone. Due to the hierarchical impact, the problem extends to all services and systems that rely on it. In our scenario, any services, applications, or virtual systems that depend on the infected Windows 10-1 or Ubuntu 1-1 machines as a gateway to reach other subnets or external networks will also be disrupted.

  -

  Victim connected to a Layer 3 switch: In our educational network, we assumed that PC7 and Win10-2-1 devices are connected directly to the Layer 3 switch IOU6. Although they are connected to the same switch, each of them belongs to a different subnet. As shown in Figure 16, when Win10-2-1 becomes infected by our malware, it will lose connectivity to the IOU6 switch due to a change in the entries of its routing table. Thus, it loses access to all other subnets in the network since IOU6 here performs Layer 3 routing based on IP addresses. This indicates that our malware may have a greater impact on devices directly connected to the Layer 3 switch, where their connection to other subnets depends entirely on IP routing. Additionally, any devices or services that rely on the infected Win10-2-1 will also be disrupted due to the hierarchical impact of our proposed malware.

5.4.2. Infection Success Ratio Evaluation

To evaluate the effectiveness of the proposed DCmal-2025 malware, we introduce a metric called the “Infection Success Ratio.” We design this metric to measure the amount of disruption that DCmal-2025 can cause within a specific network topology. The Infection Success Ratio, presented in Equation (4), is calculated as the ratio of the number of affected services and devices to the total number of available services and devices in the target environment. Below are the notations that we used:

• NRS: Number of network-based running services associated with a device.
• ML3: Number of network devices reachable through the Layer 3 switch.
• $\alpha$: Number of network devices infected by malware ($\alpha \in NDT$).
• DCmal-2025: Proposed malware.
• NDT: Total number of devices in the institution’s network topology.
• i: The index of the infected devices within $\alpha$.
• j: The index of the device within the overall NDT.

$$\mathrm{Infection}\mathrm{Success}\mathrm{Ratio}={\displaystyle \frac{{\sum }_{i=1}^{\alpha }({\mathrm{NRS}}_i\times \mathrm{ML}{3}_i)}{{\sum }_{j=1}^{\mathrm{NDT}}({\mathrm{NRS}}_j\times \mathrm{ML}{3}_j)}}\times 100\%$$

(4)

To illustrate the practical application of the “Infection Success Ratio” equation, let us examine a real example that might occur in the context of an educational institution. An attacker may target a pre-announced online exam in one of the institution’s computer labs. By deploying DCmal-2025-T2 and activating it during the exam time, the attacker could temporarily disconnect access to the exam server without producing any visible technical issues. The connection could then be automatically restored after a predefined time that the attacker had previously set. This automatic restoration prevents network administrators and technicians from easily identifying the cause of the problem.

Referring to Equation (1), the infection success ratio here is 100%, as all devices in the lab (the targeted network topology here) share the same environment and access the exam service through the Layer 3 switch. In this example, NRS represents the exam service, and ML3 corresponds to all devices in the lab connected to the Layer 3 switch. Thus, DCmal-2025 effectively denies access to the exam service to all students within the lab.

5.4.3. Possible Infection Scenarios

There are several possible infection and propagation methods that an attacker could use against the proposed educational network. These methods differ and depend on whether the attacker works internally within the network (inside the educational network) or externally (outside the educational network). Most of these methods involve social engineering techniques, in which the attacker attempts to persuade the user to trust the malicious content and execute it. An internal attacker’s job is significantly easier than that of an external attacker, as they have legitimate access to the network. On the other hand, external attackers must conduct a deeper analysis of the network and find a way to bypass the firewall before deploying the malware. Below, we categorize the infection methods based on the attacker’s location within the educational network. Each mention method is illustrated with a simple example linked to the online exam disruption case described earlier.

• Internal Attacker Infection Methods

  -

  Compromised Lab Computers: Installing the proposed malware directly on lab PCs and waiting for users to execute it. For example, an internal attacker pre-installs DCmal-2025-T2 on lab computers before the exam. Once triggered, it would disconnect the access to the network during the exam and then automatically restore the connection after a predefined time set by the attacker, leaving no one able to trace the cause of this disconnection.

  -

  Malicious Email Attachments (Phishing): This involves sending the proposed malware file to staff or students directly from an internal email. For example, an internal attacker utilizes the institution’s internal email system to send a fake exam-related email attachment. Once a student opens it, the device becomes infected, which prevents the exam from being completed successfully.

  -

  Shared Network Drive Exploitation: This involves uploading a proposed malware file to one of the internal shared drives that are commonly used within the educational environment and labeling it as one of the important files. For example, an internal attacker uploads a fake “exam materials” file to a shared drive for all students who have an exam. Once the file is opened, it infects devices.

  -

  Fake Software or Updates: This involves spreading the malware among staff or students as a rare cracked software or fake update tools. For example, an internal attacker hides DCmal-2025 as a “mandatory exam software update,” which students install before their exam.

• External Attacker Infection Methods

  -

  Malicious Email Attachments (Phishing): This involves creating a malicious link advertising news or fake scholarship opportunities, and the proposed malware is downloaded through this link. For example, the attacker emails students a malicious file containing malware from a personal account. When opened, DCmal-2025 installs and later disconnects the infected device from the exam server during the exam.

  -

  Shared Network Drive Exploitation: This involves misusing public cloud storage services such as OneDrive or Google Drive by using them to host and spread the proposed malware. For example, an external attacker could hide the malware as a “study guide” or a “test bank” shared via Google Drive. If a student installs it on lab devices before the exam, the devices will become infected, and the exam cannot be completed successfully.

6. Proposed Countermeasures

We introduce DCmal-2025 to highlight the harmful effects of routing table abuse and take a step forward in preventing hackers from exploiting this for malicious actions. To prevent infection from the proposed malware, we suggest implementing a range of preventive and defensive measures. We organize these countermeasures into four levels: the user level, endpoint level, network level, and awareness level. The target of these countermeasures is to reduce the success rate of both internal and external attacks, limit the spread of malware, and improve the detection capabilities of DCmal-2025.

6.1. User-Level Measures

A common occurrence in many shared computing environments across various institutions is that administrators and users often leave their devices unlocked, even when unattended, creating an opportunity for an internal attacker to install and execute the DCmal-2025 malware easily. To mitigate this issue, enforcing screen locks and user logouts after a predefined period will be an effective countermeasure to reduce this risk.

6.2. Endpoint-Level Measures

Another security weakness is that many end-user devices within large institutions lack practical security tools, such as host-based intrusion detection/prevention systems (HIDSs/HIPSs). This weakness makes workstations within the institution more vulnerable to malware, and any weakness in these end devices can spread the risk throughout the network. Deploying endpoint security solutions such as HIDSs/HIPSs or endpoint detection and response (EDR) can help in detecting and monitoring any suspicious behavior, such as unauthorized changes to system files or network settings.

In addition to the technical protection mentioned, it is also crucial to enforce strict privilege management policies, particularly for sensitive system components, such as the routing table. As demonstrated in this paper, the risks posed by DCmal-2025 arise mainly from the misuse of administrative privileges. To mitigate this risk, institutions should apply the principle of least privilege and limit unnecessary administrative privileges. By doing so, even if a user is tricked into executing malware, its ability to manipulate critical system components such as the routing table will be significantly limited.

Moreover, our findings showed that DCmal-2025 successfully bypasses several antivirus engines, indicating a crucial gap in current defenses. Therefore, endpoint solutions, particularly EDR systems, should be regularly enhanced and updated to detect DCmal-2025 and such threats that abuse legitimate administrative commands. This recommendation aligns with one of the main goals of our paper: to raise awareness and improve defensive tools against such overlooked attack techniques.

6.3. Network-Level Measures

Since DCmal-2025 targets the routing table, it can create a DoS condition that may be very harmful in some systems, especially critical ones. It is essential to periodically monitor the routing table and compare its status across different checks. If there are any unexpected changes in the routing table, the administrator should be notified immediately and informed of any suspicious changes. Moreover, if the routing table monitoring results are linked with other security tools, such as Security Information and Event Management (SIEM) systems, it will help correlate these events with other suspicious behaviors, thereby enhancing the accuracy and speed of detection.

6.4. Awareness-Level Measures

As mentioned earlier, social engineering is one of the most common tactics used by attackers [9]. There are many kinds of social engineering techniques; phishing is one of the most common and effective methods. It is one of the main attacks that both internal and external actors target. According to a 2024 report published by the Federal Bureau of Investigation’s Internet Crime Complaint Center, phishing and spoofing were the most frequently reported cybercrimes in 2024 [76]. Implementing advanced email filtering at the institutional level is our recommended measure to reduce the risk of malware infection through social engineering tricks, especially phishing. This solution aims to enhance institutions’ security by scanning all received email attachments to block any suspicious links before they reach users’ inboxes. However, technical defense alone is not enough; the institution should increase user awareness by conducting regular training sessions to help system users recognize the dangers of downloading and executing any file, even if it appears to be a standard or trusted file. Additionally, sending periodic awareness emails to all users may help them remain aware of this risk.

7. Ethical and Legal Considerations

To avoid ethical and legal issues, we conducted our experiments in a fully isolated test environment using VirtualBox and the GNS3 network simulator. Moreover, we neither attacked any real machine on a public network nor attempted to distribute the DCmal-2025 file outside of our controlled lab setup.

The simulated network topology used in this research is designed to mirror the structure of an educational institution’s network; however, it remains strictly virtual. The purpose of developing DCmal-2025 was not to inflict harm or enable malicious use but to highlight the harmful impact of malware that misuses legitimate routing commands. To support responsible disclosure, we submitted the source code and executable files to VirusTotal for analysis to help other antivirus vendors and the security community become aware of this type of malware and enable them to improve their detection capabilities.

Finally, to prevent the misuse of our DCmal-2025 malware or any of its variants, we strictly limit the execution to controlled environments. Additionally, we published only the algorithm and analysis of the malware variants, without releasing any code related to the malware proposed. Moreover, we frame our results with a defensive perspective. These safeguards ensure that our contribution strengthens cybersecurity defenses without providing practical tools to attackers.

8. Conclusions

In this paper, we present a novel PoC malware, DCmal-2025. This new malware is designed to illustrate the potential harm that could be caused by misusing standard routing commands and manipulating a system’s routing table. Our primary goal was to raise awareness about how such threats can disrupt networks, especially in systems that rely on continuous network availability to maintain everyday activities. We have selected an educational institution as a case study in this research to apply our proposed malware and observe its impact.

Our intent was not to cause harm or engage in malicious actions. We ran all experiments within a fully isolated virtual environment using VirtualBox and GNS3. Furthermore, we submitted both types of malware samples to the VirusTotal platform to support antivirus vendors and researchers in identifying and defending against similar threats. The results of the VirusTotal scan showed that the detection rate of antivirus engines was very low. When using the C programming language to develop both types of proposed malware, Windows executables were detected by 7.04% of antivirus engines for Type 1 and 9.72% for Type 2. These scan results are a clear indicator of the stealthiness of DCmal-2025 malware. When we reimplemented the samples using the Rust programming language, the detection rates decreased, with Type 1 flagged by only 1.39% and Type 2 by 4.17% of antivirus engines. This drop in rate demonstrates how modern programming languages can improve evasion capabilities against traditional and even enterprise-grade antivirus solutions.

This study can be classified mainly as offensive research, which we conducted in controlled and isolated environments. It contributes to a deeper understanding of how this malware operates and functions, providing valuable information that can serve as a basis for future studies in this field. The knowledge gained from our research is essential for system defenders, providing a foundation for the future development of intelligent and resilient defensive mechanisms and proactive defense strategies.

As future work, we plan to test DCmal-2025 in other network configurations and expand the target platforms to additional operating systems, such as Android. We will also design new variants that incorporate more advanced evasion techniques. Additionally, we plan to conduct a structured comparison between the C and Rust implementations of DCmal-2025. This comparison will analyze how compiler options, optimization settings, and obfuscation techniques affect detection rates, providing a deeper understanding of how the choice of programming language influences malware stealth and evasion by antivirus systems. Building on our current case study in an educational environment, we plan to evaluate DCmal-2025 in more complex and diverse settings, such as critical-infrastructure-like networks. Studying DCmal-2025 in these contexts will provide a clearer understanding of how routing-table manipulation can impact systems where availability is crucial and will also support the development of stronger defenses. Finally, we aim to incorporate deeper, dynamic behavioral analysis (e.g., customized sandboxing and dedicated EDR/XDR monitoring) to complement our current static evaluation and further enhance the scientific validity of our results.