NetGuard: A Hybrid Framework for Intelligent and Scalable Malicious URL Detection

Abstract

Due to the indispensable use of the internet, malicious actors have exploited URLs as a threat source of network information security and integrity. URL detection based on traditional methods has become inefficient against the uncontrolled increase of URLs, especially when facing dynamic and large-scale threats. To address the limitations of traditional methods and to provide intelligent and scalable detection of malicious URLs, this study proposes the hybrid framework (NetGuard) by integrating probabilistic data structures (PDSs) with machine learning (ML) capabilities. The proposed NetGuard utilizes PDSs to develop a Hybrid Scalable Detection Filter (HSDF), which combines the strengths of counting Bloom filters (CBFs) (deletion capability) and Scalable Bloom filters (SBFs). The proposed HSDF provides efficient membership queries under bounded false-positive rates (approximately 0.01) and ensures efficient data management and low-latency lookups on a scale of 10⁻⁵ s. On the other hand, NetGuard leverages the ML classifier capabilities to train and package a learned classifier for detecting malicious URLs. The proposed framework utilizes Decision Trees (DTs) and Random Forest (RF) classifiers. The proposed classifiers are trained by a novel SupURLsIdDs dataset which includes fifteen distinctive lexical and structural URL features extracted from four URL classes: benign, defacement, malware, and phishing URLs. The experimental results indicated the effectiveness of the HSDF in insertion and deletion operations, with minimal memory consumption (approximately 2.7 MB for 222,000 URLs) while maintaining a controlled false-positive rate (approximately 0.01 on Real-only subset up to 0.12 with synthetic data). The HSDF memory footprint represents a 99.88% enhancement compared to the RF model (which demands 2253.17 MB); thus, the HSDF complements RF as an ultra-lightweight first line of defense. The ML classifiers showed the superiority of RF, which achieved an overall classification accuracy of approximately 96% on large-scale URL data. These experiments are conducted using benchmark datasets constructed from aggregated real and synthetic data to demonstrate the scalability, adaptability, and resource efficiency of the first phase of NetGuard as a practical foundation for real-time web threat detection. The real-time integration and dynamic updates are presented as a deployment architecture and constitute future work.

1. Introduction

The increasing number of internet users and the rapid growth in global data volumes have significantly heightened the complexity of detecting malicious URLs, which are dynamic and ever-changing by nature [1]. This complexity comes from the limitations challenging traditional solutions, primarily centralized blacklist-based systems and standalone machine learning (ML)-based techniques [2,3]. The core limitation of blacklist-based systems is their static nature. These systems depend heavily on maintaining massive and monolithic databases of known malicious URLs; thus, they suffer from a lack of constant updates, making them ineffective against new and unknown attacks [4]. Moreover, this continuous growth of the internet traffic causes these systems’ lookup costs to scale poorly, making them suffer from significant challenges related to resource management and scalability. Concurrently, standalone ML-based solutions have capabilities of generalization and adaptation to face new threats [5]. Despite this, these systems suffer from heavy computational cost and long response time, which limit their effectiveness when applied in environments that require an immediate response, rendering them impractical for inline, ultra-low-latency deployment environments [6]. Furthermore, despite the efficiency of probabilistic data structures (PDSs)-based solutions, such as Bloom filter (BF)-based solutions, in short-time item lookup membership (e.g., malicious URLs) with minimal memory consumption, they suffer from durability and static sizing constraints [7]. As a result, they create a critical gap in real-time efficiency and adaptability when dealing with dynamic environments due to a lack of dynamic updates that incorporate new malicious patterns [8].

Motivation: Despite the effectiveness of the above approaches, integrating multiple solutions is sometimes necessary to achieve an optimal result. This is done by proposing a multi-layered approach that leverages the strengths of different detection mechanisms whereas addressing their individual limitations. Beyond URL classification accuracy, the practical challenge lies in designing a scalable and resource-efficient security mechanism that can operate under the high-volume and dynamic conditions of modern web infrastructures. In addition, relying on a single detection mechanism may limit the adaptability and effectiveness of the system when facing diverse and evolving web-based threats. The previously mentioned challenges are the main motivation for this paper.

Accordingly, the main objectives of the present study are as follows:

• Propose a framework that combines PDS and ML to achieve a balance of efficiency, adaptability, and scalability.
• Integrate the proposed framework with an external validation system to enable real-time updates of the malicious URL repository.
• Propose an implementation strategy for the framework as a multilayer to reduce time and space consumption.
• Compile and evaluate a baseline lexical/structural feature set for malicious URL identification by utilizing the used dataset.

The core contributions of this paper, achieved through the above objectives, include:

• The proposal of a novel malicious URL detection framework, named NetGuard, which utilizes the capabilities of counting Bloom filter (CBFs) and scalable Bloom filters (SBFs) in proposing the Hybrid Scalable Detective Filter (HSDF), a novel lightweight, and efficient probabilistic filter. NetGuard combines the HSDF with ML to efficiently manage a growing set of URLs, support the deletion of outdated entries, and maintain high query performance.
• The construction and public release of a novel supervised dataset, SupURLsIdDs, which is publicly available on IEEE DataPort [9] to facilitate repeatable research in analyzing malicious URLs.
• The development and evaluation of supervised ML classifiers based on Decision Trees (DTs) and Random Forests (RFs) using the proposed feature set, demonstrating strong classification performance on large-scale URL data.
• The implementation and validating the scalability, sustainability, and accuracy of the Construction Phase of NetGuard.
• The presentation of a conceptual deployment architecture for the Detection Phase of NetGuard, illustrating how the validated Construction Phase components can be integrated into a real-time system, which is identified as future work.

2. Theoretical Background and Probabilistic Data Structures (PDSs)

The foundational theoretical background behind the design and functionality of the proposed NetGuard framework is presented in this section. Here, the information engineering concepts and the employed PDS-based filter types are described.

2.1. Foundation of Information Engineering

Information engineering is a multidisciplinary field that aims to mitigate the dimensionality curse phenomenon. This is done by designing and developing systems capable of efficiently handling and processing large-scale data. To address the challenges associated with handling dynamic datasets, the field of information engineering combines techniques from computer science, data analytics, and systems engineering [10]. These involve techniques for feature extraction, decision-making, and utilizing PDS to enhance data storage and retrieval. These are crucial in designing real-time secure systems, where rapid and precise data analysis is essential.

2.2. Bloom Filter (BF)

The Bloom filter, introduced by B. H. Bloom in 1970 [11], is a highly space-efficient probabilistic data structure to approximate set-membership testing [12]. It consists of a bit array of m bits, initially all set to zero, and k independent hash functions. To add an element, its k hash values determine k bit positions, which are then set to 1. A query checks if these k positions are all 1. If so, the element is “possibly in the set” (a false positive is possible); otherwise, it is “definitely not in the set.” The probability of a false positive (P_fp) is crucial, approximated by:

$$P_{fp}\approx {\left(1-e^{kn/m}\right)}^k$$

(1)

where n is the number of inserted elements. The optimal number of hash functions ($k$) is computed using:

$$k=\left(m/n\right)\ln 2$$

(2)

Despite its efficiency, the standard BF faces significant limitations. The most significant of these is that it does not support deleting stored elements. This limitation arises because deleting requires resetting the corresponding bit to zero, which in turn can affect other elements that reference the same bit, leading to false negatives. This restricts the applicability of standard BF’s application in systems that handle dynamic data. Furthermore, another significant limitation arises when introducing more elements, as this can saturate the bit array, leading to a significantly increased false-positive rate that may exceed the design parameters.

2.3. Counting Bloom Filter (CBF)

The counting Bloom filter (CBF) was introduced by Fan et al. in 1998 to address the deletion limitation of standard BF [13]. This approach replaces the single-bit positions in the bit array by counters. To add an element, its k hash values determine k counter positions, which are then incremented. Conversely, to delete an element the k corresponding counters are decremented after ensuring that element is present in the filter. This approach avoids the false negatives and underflowing counters. A query checks if all corresponding k counters positions are not zero. If so, the element is considered “possibly in the set”. Although the CBF introduces an advantage over the standard BF, it incurs an additional cost formed by the increased space complexity. This complexity comes from the requirements of several bits for each position in the filter array instead of a single bit.

2.4. Scalable Bloom Filter (SBF)

In 2007, Almeida et al. proposed the scalable Bloom filter (SBF) as a solution that addresses the fixed capacity and monotonically increasing false-positive rate of the standard BF [14]. The main goal of the SBF is to accommodate dynamic and growing datasets while maintaining a bounded false-positive rate. This is done by composing a series of standard Bloom filters, each with increased size and a progressively looser false-positive probability. The insertion of a new element is performed in the active standard BF within the series. This process continues until the error probability exceeds the acceptable level, or the active BF is full. In both cases, the SBF creates a new, larger BF and adds it to the series. This new filter has a higher maximum capacity, and a slightly higher acceptable false-positive rate compared to the previous filter. The element to be stored is then added to the new filter. When an item is queried, all Bloom filters in the series are examined sequentially. If the item is found in any of the filters, it is considered likely in the set. Otherwise, it is considered not in the set. By this characteristic, the SBF has the ability to deal with the dynamic and massive nature of the data while ensuring that the overall false-positive probability remains below a predefined maximum global error rate. This is achieved by relaxing the false-positive rates of successively newer and larger filters. This increases the capacity of these filters without requiring an exponential increase in size. The global false-positive probability, P_global, of an SBF that contains N BFs, each with its own P_fp,i, the following approximation is used:

$$P_{global}=1-{\displaystyle {\prod }_{i=1}^N}\left(1-P_{fp,i}\right)$$

(3)

3. Related Work

The increasing use of and reliance on the internet has exposed users to the risk of malicious URLs, which directly threaten the security and integrity of their devices. Such URLs are designed to compromise data security or disrupt critical systems at both individual and organizational levels [15]. Consequently, the reliance on effective methods for detecting malicious URLs is essential. Due to the dynamic nature of these URLs, the traditional commercial systems (e.g., blacklists) are becoming inefficient. Despite their effectiveness when dealing with static environments, they lack comprehensiveness and the ability to detect newly emerging malicious URLs. For this reason, many ML-based studies have been proposed to enhance the effectiveness of malicious URL detection [16].

In [17], the researchers proposed a real-time system that uses seven ML models to detect phishing websites with an accuracy of up to 97.98%. The main features extracted in this study rely on natural language processing (NLP) features and word vectors. As a result, the system struggled to detect phishing websites that use short URLs lacking obvious malicious indicators. Furthermore, the NLP-based feature extraction method heavily relies on predefined keyword lists, which require frequent updates to maintain their effectiveness. In addition, the significant memory allocation requirements could potentially slow down the entire system. Therefore, the method is considered computationally expensive, as it must be performed for each URL. To overcome the limitations in conventional approaches that utilize manual feature engineering, the author of [18] presented a deep learning-based model designed to perform classification on each URL with 0.002% FPR, despite being seen before, leading to redundancy when processing frequently occurring phishing attempts. Therefore, such a model is computationally expensive, leading to increased latency when detection is performed in real-time. On the other hand, the authors in [19] proposed a model that uses both character-level and word-level representations of URLs instead of relying on feature engineering. The proposed Texception, a deep learning model to classify URLs as benign or phishing with a 48% True Positive Rate (TPR). Although the paper states that the proposed model is scalable, it lacks a thorough computational performance analysis clarifying inference speed and resource consumption against other models. In addition, every URL should be fully processed through the deep learning model, which adds computational overhead.

One effective way to extract discriminative features for identifying such URLs is by analyzing their lexical characteristics. These features are derived from the structure and composition of the URL itself, without requiring access to the website’s content. The authors in [20] explore detecting phishing URLs using five ML models, SVM, LR, K-NN, NB, and RF. Although this study provides an accuracy up to 99%, it focuses on using only lexical features extracted from the URLs, bypassing dynamic URL features which require further processing. However, the proposed system must scan all the URLs, which increases the processing time and slows detection for large-scale datasets. On the other hand, the paper in [21] focuses on extracting and selecting dynamic URL features such as host-based and correlated features, in addition to static features, i.e., lexical features. The paper proposes an ML-based system for URL classification. The proposed system has a slow lookup rate, since each URL must be fully processed. In addition, it requires high storage because storing and searching through a large URL dataset requires significant memory.

K. Nandhini [22] shows that a Bloom filter is ideal for streaming data due to the space efficiency and fast lookup times it provides. The author uses a cross-reference design which reduces false positives, ensuring safe browsing for children. However, the implementation does not leverage advanced variants of Bloom filters such as the counting Bloom filter. The paper only uses the standard Bloom filter which does not support deletions. In addition, using the second cross-reference Bloom filter does not guarantee a false-positive-free result. Moreover, it doubles the memory overhead, which can be avoided using a single, intelligent Bloom filter design.

Pedro Reviriego et al. [23] explore the security of learned Bloom filters (LBFs), which are extensions of standard Bloom filters developed to reduce memory requirements for membership checking, utilizing ML models. Although LBFs decrease false-positive rates, they become susceptible to mutation attack by generating new elements that can be classified as positives, leading to an increase in false-positive rates. In addition, attackers can exploit the LBF architecture and ML features to create negative elements that are mistakenly classified as positives. Finally, double-checking elements with hash functions comes with trade-off between memory consumption and computational efficiency.

R. Patgiri et al. [24] introduce a URL detection system that integrates Bloom filters and deep learning for URL classification. The paper presents a 2 DBF that enhances traditional Bloom filters by minimizing false positives and memory usage. The lookup efficiency is optimized by using two Bloom filters: the first one is used to detect malignant URLs, whereas the second one is used to detect benign URLs. In addition, the authors utilize evolutionary CNNs to classify unknown URLs. Although the proposed system updates its filters dynamically, it does not clearly explain how to handle new attack patterns that could go unnoticed by the existing system. Moreover, the paper does not provide a comparison with other state-of-the-art systems, such as state-of-the-art hybrid architecture. Table 1 illustrates the key findings and limitations of the related recent studies.

The increasing number of internet users and the rapid growth in data volume add complexity to detecting malicious URLs, which are dynamic and ever-changing by nature. This complexity comes from the limitation that challenges the traditional solutions such as blacklist systems and ML-based techniques. The core limitation of blacklist-based systems is their static nature. These systems depend heavily on maintaining comprehensive databases of known malicious URLs and suffer from a lack of constant updating, making them ineffective against new and unknown attacks. Moreover, this continuous growth of the internet traffic has caused these systems to suffer from significant challenges related to resource management and scalability. On the other hand, the ML-based solutions have capabilities of generalization and adaption to face the new threats. Despite this, these systems suffer from high computational cost and long response time, which limit their effectiveness when applied in environments that require immediate response. Furthermore, the PDS-based solution, such as Bloom filter (BF)-based solutions, suffer from durability and scalabilities issues when they are not dynamically updated to include new malicious patterns. Despite their efficiency in checking item membership (e.g., malicious URL) in a very short time, with minimal memory consumption, they create a critical gap in real-time efficiency and adaptability when dealing with dynamic environments. To address these challenges, an innovative solution that integrates lightweight data structures and advanced verification mechanisms is required. Such a solution can enhance the robustness, accuracy, efficiency, and reliability of malicious URL detection.

Table 1. The recent malicious URL detection studies.

Ref.	Approach Category	Key Technique(s)	Limitations	Dataset
[17]	ML	ML, NLP-based features, word vectors	Relies solely on URL analysis, depends on predefined keyword lists (requires frequent updates), significant memory, computationally expensive	Ebbu2017 Phishing Dataset
[18]	DL	CNN, attention-based hierarchical RNN	Redundancy in processing, computationally expensive, increased latency	Custom dataset
[19]	DL	Character/word-level deep learning	Lacks thorough computational performance analysis, computational overhead per URL	Microsoft’s anonymized browsing telemetry data
[20]	ML	SVM, LR, K-NN, NB, RF (lexical features)	Must scan all URLs (increased processing time, slow for large datasets)	UNB 2016 dataset
[22]	PDS	Standard Bloom Filter	No deletion support, does not guarantee 100% false-positive free, doubles memory overhead with cross-reference design	Kaggle URL Classification Dataset
[23]	Hybrid (PDS + ML)	Learned Bloom Filters (LBFs)	Susceptible to mutation attacks, can increase false-positive rate (FPR), trade-offs in memory/computational efficiency	Custom dataset
[24]	Hybrid (PDS + DL)	2DBF, Evolutionary CNN	Does not clearly explain handling new attack patterns, lacks comparison with state-of-the-art hybrid architectures	Not specified

Table 1. The recent malicious URL detection studies.

Ref.	Approach Category	Key Technique(s)	Limitations	Dataset
[17]	ML	ML, NLP-based features, word vectors	Relies solely on URL analysis, depends on predefined keyword lists (requires frequent updates), significant memory, computationally expensive	Ebbu2017 Phishing Dataset
[18]	DL	CNN, attention-based hierarchical RNN	Redundancy in processing, computationally expensive, increased latency	Custom dataset
[19]	DL	Character/word-level deep learning	Lacks thorough computational performance analysis, computational overhead per URL	Microsoft’s anonymized browsing telemetry data
[20]	ML	SVM, LR, K-NN, NB, RF (lexical features)	Must scan all URLs (increased processing time, slow for large datasets)	UNB 2016 dataset
[22]	PDS	Standard Bloom Filter	No deletion support, does not guarantee 100% false-positive free, doubles memory overhead with cross-reference design	Kaggle URL Classification Dataset
[23]	Hybrid (PDS + ML)	Learned Bloom Filters (LBFs)	Susceptible to mutation attacks, can increase false-positive rate (FPR), trade-offs in memory/computational efficiency	Custom dataset
[24]	Hybrid (PDS + DL)	2DBF, Evolutionary CNN	Does not clearly explain handling new attack patterns, lacks comparison with state-of-the-art hybrid architectures	Not specified

4. Methodology of NetGuard

The main goal of the NetGuard is to integrate the PDS with data processing, feature extraction, and decision-making to provide internet users with a robust mechanism for detecting and identifying the malicious URLs. In addition, it provides a dynamic update mechanism for its internal dataset, enabling it to serve as a current and reliable resource that can be serve as an up-to-date dataset of the malicious URLs that will be used by other applications, including traditional and learning-based applications, thereby enhancing URL safety detection. To achieve the intended goal, the proposed NetGuard operates in two primary interconnected phases that work together: the Construction Phase and the Detection Phase. The Construction Phase consists of two key components: the Filter Construction Module and the Classifier Construction Module. Only this phase is implemented and experimentally validated. In this phase, the used dataset is first used as a raw dataset to build the proposed HSDF. Concurrently, the same dataset is reprocessed to prepare it for training the ML model. The raw dataset contains 651,191, records which are used as input to the proposed ML pipeline, along with the key parameters for learning the ML model. The ML models are trained and tested on a 70:30 ratio of the used dataset, meaning approximately 455,833 samples for training and 195,358 samples for testing. The ML model configuration is refined through a hyperparameter tuning process using the automatic k-fold cross-validation provided by the Scikit-learn library to identify optimal parameter values.

In the Filter Construction Module, we propose a novel probabilistic filter called the Hybrid Scalable Detection Filter (HSDF) as the core of the malicious URL detection system within NetGuard to address the limitations of static Bloom filter structures in a dynamic and evolving cybersecurity environment. The HSDF combines the strengths of CBF—which support deletion operations—and SBF—which accommodate unbounded growth while maintaining a low false-positive rate. This approach makes sure that NetGuard can easily handle a rising number of URLs, delete old ones, and keep query performance high.

On the other hand, the Classifier Construction Module focuses on data processing, feature engineering, and developing an optimal classification model to categorize incoming URLs.

The second phase, called the Detection Phase, uses these built parts in a multi-step procedure to check the safety of the incoming URL. Consequently, this phase updates the dataset used for training, with newly identified malicious URLs, to ensure it remains current.

Figure 1 provides a high-level overview of the proposed NetGuard architecture. The detailed work of the first phase is presented in the next subsection. This paper focuses exclusively on the Construction Phase, which includes the Filter Construction Module and the Classifier Construction Module. These modules form the essential infrastructure necessary for scalable malicious URL filtering and have been completely implemented and experimentally assessed in this work. The Detection Phase, which includes checking URLs in real time, having the HSDF and the trained ML classifier operate together, and making changes based on live traffic monitoring, is shown as a conceptual deployment workflow. The implementation and real-time validation are outside the scope of this paper and are recognized as a principal focus for future research.

4.1. Dataset Sourcing and Profiling

The raw URL repository utilized in this study is a curated collection of URLs or websites compiled from various sources to ensure broad representation across diverse threat types. This repository consists of 651,191 URLs. Those URLs are grouped into four classes, including 428,103 benign or safe URLs, 96,457 defacement URLs, 94,111 phishing URLs, and 32,520 malware URLs. Figure 2 illustrates the class distribution of URLs across the four classes.

Moreover, the baseline characteristics and sources of the utilized dataset are presented in Table 2. This transparent presentation is vital for reproducibility and for accurately interpreting the scope of the model’s training and evaluation.

As shown in the above figure, the dataset is highly imbalanced, with the benign class dominating the dataset and accounting for 65.74% of the samples, whereas the malicious classes, represented by defacement, phishing, and malware, occupy significantly smaller proportions. This imbalance enforces careful handling during training the ML classifier to avoid bias toward the majority class.

Table 2. Baseline characteristics of the utilized raw URL dataset.

Category	Number of URLs	Data Sources
Benign	428,103	ISCX-URL-2016 dataset [25], Faizan Git repository [26]
Defacement	96,457	ISCX-URL-2016 dataset [25]
Phishing	94,111	ISCX-URL-2016 dataset [25], Malware Domain Blacklist dataset, PhishTank dataset [27], and the PhishStorm dataset [28]
Malware	32,520	ISCX-URL-2016 dataset [25], Malware Domain Blacklist dataset
Total	651,191

Table 2. Baseline characteristics of the utilized raw URL dataset.

Category	Number of URLs	Data Sources
Benign	428,103	ISCX-URL-2016 dataset [25], Faizan Git repository [26]
Defacement	96,457	ISCX-URL-2016 dataset [25]
Phishing	94,111	ISCX-URL-2016 dataset [25], Malware Domain Blacklist dataset, PhishTank dataset [27], and the PhishStorm dataset [28]
Malware	32,520	ISCX-URL-2016 dataset [25], Malware Domain Blacklist dataset
Total	651,191

4.2. Feature Engineering

Feature engineering involves utilizing data domain knowledge to provide more informative features. These features are used to improve the ML algorithms’ performance. In this study, the normalization and feature extraction of the URLs are the main steps in constructing the proposed NetGuard’s detection solution. URL feature extraction is the key process for ML techniques in tasks such as malware analysis, malicious URL detection, and website classification. It involves detecting patterns and characteristics that have a crucial impact on distinguishing different types of URLs. It also includes changing the URL into a numerical format that is used to train ML models. This transformation is performed by finding and identifying various patterns of a URL. The types of URL features typically extracted include lexical features and structural features [20].

URL’s Cleaning

To ensure the integrity, consistency, and generalizability of the aggregated dataset, a rigorous data cleaning and quality control pipeline was established.

• Normalization and domain-level similarity: In the context of this study, URL normalization relies on transforming the various representations of the URLs into a canonical and consistent form. This process plays an essential part in feature engineering as it helps treat different URLs pointing to the same resource as duplicates. Normalization facilitates handling huge amounts of data and improves convergence and prediction accuracy during model training [29]. Besides, the URLs normalization has a vital role in feature extraction. Through extracting the specific parts of URLs, like domain, path, they can be used as an extracted features ready for training a ML model [30].

The process typically involves several steps [31]:

• Using consistent separators instead of the separator characters (e.g., / and ‘\’).
• Extracting and deleting the redundant elements (e.g., index pages, port numbers, and trailing slashes).
• Decapitalizing all characters for consistency.
• Implementing domain extraction procedure to monitor the domain distributions across the categories and guarantee that the classifiers capture deep lexical features rather than biased domain names.
• Deduplication and overlap elimination: Because the dataset is a curated collection of URLs or websites compiled from various sources, overlap was a major concern. The deterministic string-matching method is applied on the full URL paths to eliminate the records that share identical string hashes and ensure that all records are structurally unique across the four classes.
• Temporal leakage: The data has no time sequence, but to prevent leakage and avoid the artificial inflation of classification performance, a stratified splitting technique is used. Data is carefully split using a 70:30 ratio between training and testing sets, ensuring that the structural traits of different sources do not leak between these sets.

4.3. Filter Construction Module

The Filter Construction Module is responsible for designing and building the Hybrid Scalable Detection Filter (HSDF), a novel probabilistic filter that forms the core of NetGuard’s malicious URL detection system. The HSDF is designed to evaluate URL membership against a repository of known malicious URLs. The HSDF is specifically engineered to address the inherent limitations of static Bloom filter structures within the dynamic and ever-evolving cybersecurity environment. It achieves this by combining the strengths of CBF, which support deletion, and SBF, which accommodate unbounded growth, while maintaining a low false-positive rate. This design ensures that NetGuard can efficiently handle a growing set of URLs, support the removal of outdated entries, and preserve query performance. The HSDF extends the traditional Bloom filter by replacing the bit array with an array of counters.

Initially, the raw dataset is filtered to retain only the malicious URLs. Each malicious URL is treated as an element to be inserted into the proposed HSDF. Each element x is hashed using K independent hash functions, and the corresponding counters are manipulated as follows:

Insertion:

Let h₁(x), h₂(x), …., h_k(x) be the independent hash functions (K), and C_i be the counter array of size m_i for the filter F_i. For an element x:

$$\forall k \in \left[1,K\right], C \left[h_k\left(x\right)\right]\leftarrow C \left[h_k\left(x\right)\right]+1$$

(4)

Query (to check if an element x is present):

$$Query\left(x\right)=\{\begin{array}{c}True, if \forall i, C \left[h_k\left(x\right)\right]>0\\ False, otherwise\end{array}$$

(5)

Deletion:

$$\forall k \in \left[1,K\right], C \left[h_k\left(x\right)\right]\leftarrow \mathrm{m}\mathrm{a}\mathrm{x}\left(0, C \left[h_k\left(x\right)\right]-1\right)$$

(6)

The scalability aspect of the HSDF is inspired by the SBF model proposed by Almeida et al. [14]. When the current CBF within the HSDF reaches its item capacity threshold n_max, a new filter is appended, with a tighter false-positive rate. The error rate for each new filter is reduced geometrically, as shown in the following equation:

$${ϵ}_i= {ϵ}_0.r^i$$

(7)

where:

• ${ϵ}_0$: initial false-positive rate (e.g., 0.01);
• r: tightening ratio (e.g., 0.5);
• i: index of the filter layer.

This strategy ensures that the cumulative false-positive rate across all filters remains bounded, given by:

$${ϵ}_{total}={\displaystyle \sum _{i=0}^{\mathrm{\infty }}}{ϵ}_0.r^i = {\displaystyle \frac{{ϵ}_0}{1-r}} ,\hspace{1em}\hspace{1em}for 0<r<1$$

(8)

The tightening ratio r used in the construction of HSDF is set to 0.5, following a geometric error allocation strategy commonly used in scalable probabilistic filtering structures to ensure that the cumulative false-positive probability remains bounded as additional layers are introduced. The HSDF consists of a list of independently managed filters. New filters are appended when the active one reaches its predefined item limit n_max. The system ensures the following processes: insertions occur only in the latest filter, lookups traverse all filters in sequence until a match is found, and deletions are precise, occurring only in the filter where the item is found.

This layered design ensures both temporal efficiency and structural flexibility. Each newly created filter maintains a count of inserted items and can thus signal when its capacity is exhausted. The memory consumed by each created filter is a function of its size m and the counter size (typically 4 bytes per counter):

$${memory}_{each\_filter}= m . {size}_{counter}$$

(9)

The value of m for each filter is chosen based on the number of items n and desired error rate ϵ, using the classic Bloom filter equation [32]:

$$m=-{\displaystyle \frac{n\mathit{ln}\left(ϵ\right)}{{\left(\mathit{ln}2\right)}^2}}$$

(10)

$$K={\displaystyle \frac{m}{n}}.\mathit{ln}2$$

(11)

where K is the optimal number of hash functions.

Figure 3 shows the flowchart diagram of the HSDF main process, where (a) represents the addition (insertion) process, whereas (b) represents the other processes (lookup and deletion).

The HSDF is deployed in the Construction Phase of NetGuard as part of the Filter Construction Module. It serves to validate newly encountered URLs by checking against authorized or malicious entries. In the Detection Phase, the HSDF plays a critical role in ensuring low-latency lookups, while enabling real-time updates (insertions/deletions) of URLs. Its scalable nature allows NetGuard to evolve with the threat landscape without compromising accuracy or resource efficiency. The design of HSDF represents a significant advancement, as it effectively synthesizes the counter-based mechanism of CBF with the layered, growth-accommodating structure of SBF. This integration allows NetGuard to achieve both efficient deletion and unbounded scalability with a controlled false-positive rate, thereby overcoming the cumulative limitations inherent in prior PDS designs.

4.4. Classifier Construction Module

The primary objective of this module is to construct a robust and accurate classification model capable of distinguishing between malicious and benign URLs. To accomplish this, the module comprises two sequential and interrelated stages: feature engineering and classifier building. The feature-engineering stage processes the raw data to prepare it for classifier training. Therefore, this section provides the classifier-building stage with more informative features, enhancing the ML classifier’s performance. The output of the classifier-building stage is the learned classifier model. Figure 4 illustrates the ML pipeline of the Classifier Construction Module stages, which are described below.

4.4.1. Feature-Engineering Stage

As shown in Figure 4, in this stage, each URL undergoes a normalization process designed to standardize its structure and eliminate superficial variations. This includes converting all URLs to lowercase and removing any leading or trailing whitespace, removing common prefixes such as http://, https://, and www., and stripping any trailing slashes. The normalized URLs are then subjected to feature extraction, where a comprehensive set of discriminative attributes is derived. These features are grouped into three primary categories. The first category includes lexical features, which are extracted directly from the normalized URL string, such as the number of special characters, digit count, URL length, entropy, the length of the top-level domain (TLD), and hyphen. The second category includes structural features, which are derived after parsing the URL, typically using a function such as Python’s urlparse function. This enables the extraction of structural features, including the number of directory levels, the use of secure protocol, the length of the hostname, the overall path length, and IP address usage. The other structural feature is the presence of the @ symbol, which is extracted from the normalized URL, as their structural significance is independent of full component parsing. The third category strategically includes the phishing-specific features, which improve recall for the challenging phishing class by detecting common suspicious strategies. These features are checking paths for suspicious keywords, the number of subdomains, and the full TLD length. Combining these three feature categories guarantees the rich and informative representation of the URLs. These lexical and structural features are derived from well-established practices in prior malicious URL detection studies and are intentionally adopted in this work as a baseline to support reproducible and large-scale evaluation. Following feature extraction, the data is forwarded to the classifier-building stage.

Table 3. Extracted URL features and their characteristics.

Feature	Meaning	Type	Derived From	Importance for Malicious Identification
URL length	Total number of characters in the normalized URL	Lexical	Using Normalized URLs	High values indicate elongated structures or parameter padding (malware, phishing).
Number of special chars	Non-alphanumeric count	Lexical		High counts indicate unclear or machine-generated (malware).
Count of digits	Numeric characters in URL	Lexical		High counts indicate unclear or machine generation (malware).
TLD length	Length of top-level domain	Lexical		General domain characteristic.
Count of hyphens	Total count of hyphens (-) in the URL	Lexical		High values may indicate deceptive domain naming (phishing).
Entropy	Shannon entropy (randomness) of the URL string	Lexical		High values are a strong indicator of using Domain Generation Algorithms (DGAs) (malware).
Full TLD length	Length of the entire domain suffix	Phishing-specific		The complex TLD structures refer to domain masking (phishing).
Has @ symbol	Boolean (1/0) indicating the presence of @ in the URL	Structural		A crucial indicator of phishing URL structures.
Count dir (slashes)	Number of ‘/’ in path	Structural	Using Parsed URLs	High value can be used as indication to cloak (defacement, malware).
Uses HTTPS	Boolean (1/0) indicating the use of the secure protocol.	Structural		May indicate the absence of official secure protocol usage.
Hostname length	Length of domain/subdomain	Structural		Abnormal length can indicate suspicious structure.
Path length	Length of URL path	Structural		High values indicate there is hidden file/page depth (malware, defacement).
Is IP	Boolean (1/0) indicating if the hostname is an IPv4 address.	Structural		Used to avoid DNS lookups/blocklists (malware, phishing).
Num subdomains	Count of dots (.) in the hostname.	Phishing-specific		High values indicate that it relies on free subdomains or domain masking (phishing).
Path contains login	Boolean (1/0) if the path contains keywords like ‘login’, ‘bank’, etc.	Phishing-specific		Direct indication of a deceptive attempt to get user trust (phishing).

provides a detailed overview of the specific features extracted and their characteristics for this study. Moreover, these extracted features, derived through our enhanced feature engineering process, are successfully integrated to generate a comprehensive labelled dataset named Supervised URLs Identification Dataset (SupURLsIdDs). The SupURLsIdDs dataset encompasses all four classes: benign, defacement, malware, and phishing.

4.4.2. Classifier-Building Stage

This stage deals with the extracted features that are passed from the feature-engineering stage. Firstly, these features are divided into training and testing subsets, following a standard 70:30 ratio. Supervised classifiers, Decision Trees (DTs) and Random Forest (RF), provided by Scikit-learn are selected as the underlying ML models for this task. The choice of these classifiers reflects a deliberate emphasis on robustness, interpretability, and reproducibility when operating on structured lexical and structural URL features. Initially, a hyperparameter tuning process is conducted using cross-validation in conjunction with grid search strategies to search for high-impact hyperparameters that, in turn, optimize the model’s performance. This tuning process is performed by fitting a 10-fold cross-validation model that is performed across a range of high-impact parameters to identify the most impactful parameters for the selected ML model that yield the best predictive performance. The Scikit-learn library’s grid search method facilitates this process by leveraging all available CPU cores for parallel processing, to decrease the consumption time required for tuning. The tuning process is applied exclusively to the training subset, while the held-out test set is used only once for final performance evaluation.

After determining the optimal parameter values, the selected ML classifier is trained on the full training set and evaluated using the test set. The models’ effectiveness is assessed using standard evaluation metrics such as accuracy [33], precision [33], recall [34], and F1-score [34]. These metrics are computed using the following equations, respectively:

$$accuracy={\displaystyle \frac{\sum \left(TP+TN\right)}{\sum \left(TP+TN+FP+FN\right)}}$$

(12)

$$precision={\displaystyle \frac{\sum TP}{\sum (TP+FP)}}$$

(13)

$$Recall={\displaystyle \frac{\sum TP}{\sum (TP+FN)}}$$

(14)

$$F1-score={\displaystyle \frac{2Precision\ast Recall}{Precision+Recall}}$$

(15)

where:

• TP: true positives (the number of correct positive predictions).
• TN: true negatives (the number of correct negative predictions).
• FP: false positive (the number of misclassified positive class).
• FN: false negative (the number of misclassified for negative classes).

Upon successful validation, the trained classifier that achieves higher performance than the other classifiers is packaged for deployment in the subsequent Detection Phase of the NetGuard system, where it is applied to unseen URLs for real-time classification.

5. Experimental Results and Discussion

This section presents and discusses the experimental evaluation of the proposed NetGuard framework. The primary objective of the evaluation is to validate its efficiency, scalability, and detection performance through its two main modules: the HSDF and the ML-based classifier. This evaluation process is performed through three key areas. First, an Exploratory Data Analysis (EDA) for the utilized dataset is performed. Secondly, the ML-based classifier accuracy for feature extraction and malicious URL detection is evaluated. Lastly, a comprehensive comparison with the state-of-the-art malicious URL detection studies is performed. The experiments were performed on a system equipped with an Apple M3 Pro chip, 18 GB of unified memory, and macOS Sequoia 15.5 (24F74). The framework was implemented in Python 3.12.5, leveraging the Scikit-learn library for the DTs and RF models and a custom-built implementation for the HSDF.

5.1. Exploratory Data Analysis (EDA) of the Dataset

Here, the exploratory analysis for the utilized dataset is represented to understand its structure, key characteristics, and class distribution of the URLs.

First, the length of the URLs is analyzed to illustrate the possible patterns distinguishing malicious from benign URLs. The URL length ranged from 1 to 2175, with a mean length of 60 and a median of 47 characters. As shown in Figure 5, the longer URLs are related to the malicious URLs, particularly phishing and malware categories. This observation illustrates how attackers exploit longer URLs to conceal malicious content, include obfuscation sequences, or combine multiple redirects.

To investigate the domain usage patterns of the URLs, the TLD of the URLs is analyzed. Figure 6 shows that .com is the dominant domain used by the URLs (398,479 URLs), followed by .org (50,844 URLs), .net (28,255 URLs), and country-specific TLDs such as .de and .co.uk. Despite the dominance of .com across both benign and malicious URLs, the attacker keeps on exploiting the lesser-known TLDs which often lack monitoring or regulation. Finally, the character composition of URLs is analyzed by counting digits and special characters. Figure 7 shows that an average of 5.53 digits and 9.40 special characters are contained, with higher counts observed in malicious URLs. At first glance, when looking at Figure 7, the benign class appears to dominate the distribution, exhibiting a higher frequency of special characters. This arises due to the imbalance in class sizes, as shown in Figure 2. The fact that this is the majority class makes the distribution curve of special characters more prominent. Therefore, to account for this effect, the relative patterns of the benign URLs should be considered. Benign URLs are condensed within a narrower range of special-character counts (from 0–15), whereas malicious URLs, represented by phishing and defacement classes, are condensed over a higher range of special-character counts. We note that the use of large numbers of digits and special characters is a common tactic for attackers to obscure a suspicious URL, imitate a legitimate URL, or attempt to bypass filters. Therefore, these patterns are used as important indicators for feature engineering and are considered a useful indicator in ML-based URL classification.

5.2. HSDF’s Performance Analysis

This section represents the evaluation results of the proposed HSDF’s performance in terms of insertion/deletion efficiency, memory footprint, and false-positive rate (FPR). The objective of this evaluation is to demonstrate the validity of the hybrid approach in combining the CBF and SBF features to support deletion and scalability, while maintaining a low FPR and high efficiency under a continuously growing dataset. To demonstrate the HSDF’s performance, we conducted two studies. The first evaluated the filter’s performance in terms of scalability compared to other filters. The second evaluated its performance in terms of deletion and retrieval accuracy.

Study 1: To evaluate the scalability of the proposed HSDF, we divide the filtered dataset, which includes only suspicious URLs (approximately 222,000 links), into four groups, each containing approximately 55,000 links. The purpose of this division is to test scalability while maintaining a constant error rate. We adopted the value of n = 55,000, which is approximately the first batch of URLs to be stored, considering the scenario of not knowing the total number in the future and treating it as a fixed environment. Based on this value, setting the error rate to 0.01, and using (10) and (11), the values of m and K are calculated, respectively. Equation (7) is used to adjust the error rate to maintain it within the acceptable values. To implement this scenario, we stream the four datasets and measure the FPR and memory consumption. Figure 8 shows the superior performance of the HSDF in maintaining a bounded false-positive rate when dealing with a dynamic environment issue which is represented by a dynamic and growing dataset. Figure 9 illustrates the memory consumption rate of the HSDF when processing the four parts of dataset. The results indicate that memory consumption increases linearly with the size of the input data. This is because, in the HSDF methodology, to maintain a bounded false-positive rate, the capacity of the active filter is checked before processing any new data to ensure it can accommodate the incoming data. When the active filter’s memory capacity is reached, a new filter is created. Thus, as the data volume increases, the proposed filter creates a new instance, resulting in an approximately linear increase in memory consumption. The memory consumption of HSDF is approximately 2.7 MB for storing 222K URLs, reflecting a compact footprint for a deletion-enabled and scalable probabilistic filtering structure operating at this scale. Instead of storing the complete details of each URL, as traditional blacklist-based systems do, the proposed filter stores only a compact representation of the URL domain names, ensuring that memory consumption remains within acceptable limits. This efficiency makes the proposed method more suitable for dynamic environments and real-time systems, where both memory efficiency and stable performance are critical.

Study 2: To evaluate the effectiveness of the proposed HSDF against the traditional CBF in terms of scalability, throughput, latency, and accuracy under different data scale and deletion conditions, three subsets of URLs are constructed. These subsets are generated to represent realistic operational conditions which are real-only subset, synthetic-only subset, and mixed subset. The real-only subset comprises URLs collected from the used filtered dataset (malicious URLs only). This subset is suitable to test the filter’s performance in practical, unaltered environments. The second one, the synthetic-only subset, contains the synthetic URLs, constructed by combining random domain structures, controlled repetition rates, and subdomain variations. It imitates high-volume and diverse URL streams that are typically run into dynamic environments but are difficult to reproduce using real data alone. This subset allows for precise measurement of performance and scalability under predictable input patterns by stress-test the verification mechanism and internal counting of filters. The last dataset, the mixed subset, combines the real and synthetic URLs in balanced proportions. This subset is used to analyze the adaptability and generalization of the proposed filter.

Figure 10 illustrates the query and deletion latency for the HSDF and CBF filters. This study omits the SBF implementation due to its inherent lack of deletion support. Both filters showed nearly constant latency values, but the HSDF maintained a slightly higher average, which is due to its dynamic nature, which forces the construction of multiple filter layers. This nature points out a justifiable architectural trade-off between the performing operations on a single contiguous memory block and navigating through multiple active filter layers to safely locate and remove an element. Furthermore, the deletion process requires metadata synchronization across all filter layers to prevent any drop in the FPR for subsequent lookups, something a traditional filter cannot provide. This latency requirement is negligible compared to the advanced improvements, including significant memory efficiency improvements of up to 99.88% compared to intelligent learning models, particularly the RF classifier (as discussed in the following section).

As a result, the throughput, as shown in the Figure 11, also showed approximate ratios, as it is directly dependent on latency values for each filter. Despite the designing goal of the proposed HSDF to improve lookup efficiency by binary search, the obtained results show that the traditional CBF achieved slightly higher throughput and lower latency. This is due to the additional computational operations required for dynamic set management and binary search operations. These, in turn, impose marginal overhead that is negligible compared to the actual goal of addressing dynamic realities while maintaining a constant false-positive rate, as shown in Figure 12, where the HSDF outperforms the traditional CBF in terms of false and residual positive rate. This figure confirms that the dynamic verification mechanism of the HSDF more accurately identifies authorized URLs when dealing with real-only scenarios, whereas in dealing with synthetic-only and mixed datasets, the HSDF exhibits moderate increase in residual positive rate. This comes from the artificial uniformity and high overlap in the synthetic data, which in turn led to higher collision probabilities among generated hash values.

It is worth noting that all the experiments conducted in Study 2 (comparing the HSDF and the CBF) are focused strictly on binary detection (malicious vs. non-malicious).

It is important to clarify how the proposed HSDF differs from existing learned Bloom filter-based approaches [23,24]. Learned Bloom filters integrate ML models directly into the membership verification process to reduce false-positive rates, which introduces inference-time dependency on learned models and increases sensitivity to adversarial manipulation or concept drift in dynamic environments. In contrast, the current HSDF implementation relies exclusively on deterministic, hash-based probabilistic data structures during lookup, as reflected in the stable latency and bounded false-positive behavior observed in the experimental results. Machine learning in NetGuard is employed during the Construction Phase to train a supervised classifier, while its role in dynamically updating the HSDF is defined as part of the Detection Phase and constitutes future work. This separation enables predictable runtime performance and positions the HSDF as a robust filtering substrate for future ML-assisted updates without incurring inference-time overhead during URL filtering.

5.3. The SupURLsIdDs Baseline

The extracted features, represented in Table 3, which are derived through our enhanced feature-engineering process, are successfully integrated to generate a comprehensive labelled dataset SupURLsIdDs. The SupURLsIdDs dataset encompasses all four classes: benign, defacement, malware, and phishing. Aware of the importance of data in accelerating scientific progress and saving time and effort for other researchers and scientists by bypassing the overwrought initial steps of cleaning raw data and extracting appropriate features capable of training ML models, we are making this enhanced and pre-processed dataset publicly available at [9].

Table 4. Baseline classes and details of the SupURLsIdDs dataset.

Class	Support (Count)	Percentage (%)
benign	428,103	65.74
defacement	96,457	14.81
phishing	94,111	14.45
malware	32,520	4.99

and

Table 5. Structural and statistical baseline details of SupURLsIdDs dataset.

Feature		Count	Mean	Std. Dev.	Min	Max
Lexical/Structural	num_special_chars	651,191	8.114	7.385	0	369
	count_digits	651,191	5.527	11.701	0	1204
	Tld_length	651,191	2.994	0.907	0	18
	url_length	651,191	57.157	43.56	1	2175
	hostname_length	651,191	16.659	11.243	0	244
	path_length	651,191	41.154	29.77	0	2175
	count_dir	651,191	2.317	1.567	0	39
	count_hyphens	651,191	1.55	2.974	0	87
	entropy	651,191	4.132	0.397	0	7.111
	num_subdomains	651,191	1.415	1.023	0	34
	full_tld_length	651,191	2.994	0.907	0	18
Binary Features	has_at_symbol	651,191	0.002	0.045	0	1
	uses_https	651,191	0.024	0.153	0	1
	is_ip	651,191	0.011	0.105	0	1
	path_contains_login	651,191	0.039	0.194	0	1

illustrate the classes, as well as the structural and statistical baseline details of the SupURLsIdDs dataset, respectively. The comprehensive structural and statistical baseline profiling of the extracted features within the SupURLsIdDs dataset, shown in Table 5, presents the wide spectrum of characteristics encapsulated in SupURLsIdDs. Furthermore, documenting these mathematical boundaries (mean, std. dev., min, max) ensures data readiness and transparency, which directly helps build distinctive ML models. As shown in Table 5, despite their low variance, binary features such as has_at_symbol and is_ip are fundamentally retained to guarantee structural resilience against future adversarial obfuscation techniques.

5.4. Classifier Tuning and Evaluation Results

This section presents the obtained tune hyperparameter for the selected ML classifiers, DTs and RF, and evaluates their performance in identifying malicious URLs using the extracted URL features.

Table 6. The hyperparameter tuning result of the DT classifier.

Parameter	Meaning	Tested Values	Best Value
criterion	Quality function of a split.	{‘gini’, ‘entropy’}	entropy
max_depth	The maximum depth of the tree.	{5, 10, 15, 20, None}	20
min_samples_split	The minimum number of samples required to split an internal node.	{2, 5, 10, 20}	2
min_samples_leaf	The minimum number of samples required to be at a leaf node.	{1, 5, 10}	1
class_weight	Weights associated with classes.	{‘balanced’, None}	None
Best cross-validation score (f1_weighted): 0.9401 ± 0.0018

and

Table 7. The hyperparameter tuning result of the RF classifier.

Parameter	Meaning	Tested Values	Best Value
n_estimators	The number of DTs in the forest.	Random int range from 100 to 500	443
max_depth	The maximum depth of each tree.	10,20, 30	30
min_samples_split	The minimum number of samples required to split an internal node.	Random int range from 2 to 9	3
min_samples_leaf	The minimum number of samples required to be at a leaf node.	Random int range from 1 to 3	1
max_features	The number of features to consider when looking for the best split.	sqrt, log2	log2
class_weight	Weights associated with classes.	[‘balanced’]	‘balanced’
Best cross-validation score (f1_weighted): 0.9552 ± 0.0011

show the searched hyperparameter ranges and the best hyperparameters for the DTs and RF classifiers, which were selected dynamically using 10-fold cross-validation, with identification accuracy as a scoring metric.

The tuned DTs and RF classifiers are then evaluated using the filtered dataset following a standard 70:30 ratio. That means that the tuned classifiers are trained using 70% from the dataset and then tested on the remaining 30% of the unseen data. Three evaluation metrics are used to evaluate the adopted classifiers, as shown in the classification report illustrated in

Table 8. Classification report for the tuned DT classifier with enhanced features.

Class	Precision	Recall	F1-Score	Support
benign	0.9588 ± 0.0014	0.9765 ± 0.0011	0.9676 ± 0.0012	128,733
defacement	0.9462 ± 0.0019	0.9645 ± 0.0016	0.9553 ± 0.0015	28,692
malware	0.9352 ± 0.0022	0.9188 ± 0.0025	0.9269 ± 0.0021	9699
phishing	0.8813 ± 0.0029	0.7949 ± 0.0035	0.8359 ± 0.0030	28,234
accuracy			0.9456 ± 0.0016	195,358
macro avg	0.9304 ± 0.0018	0.9137 ± 0.0020	0.9214 ± 0.0018	195,358
weighted avg	0.9446 ± 0.0016	0.9456 ± 0.0016	0.9447 ± 0.0015	195,358

and

Table 9. Classification report for the tuned RF classifier with enhanced features.

Class	Precision	Recall	F1-Score	Support
benign	0.9642 ± 0.0011	0.9833 ± 0.0008	0.9737 ± 0.0009	128,733
defacement	0.9681 ± 0.0015	0.9819 ± 0.0012	0.9750 ± 0.0011	28,692
malware	0.9841 ± 0.0009	0.9298 ± 0.0021	0.9562 ± 0.0014	9699
phishing	0.9071 ± 0.0024	0.8293 ± 0.0031	0.8664 ± 0.0026	28,234
accuracy			0.9582 ± 0.0012	195,358
macro avg	0.9559 ± 0.0013	0.9311 ± 0.0016	0.9428 ± 0.0014	195,358
weighted avg	0.9575 ± 0.0012	0.9582 ± 0.0012	0.9575 ± 0.0011	195,358

, respectively.

The macro avg founded in the classification report represents the arithmetic mean of all the per-class scores for each metrics. This method enforces the same handling to all classes, regardless of their support values. The weighted average considers each class’s support. The class support refers to the number of actual class instances in the dataset.

From the obtained evaluation results, the constructed RF classifier shows superior performance in identifying malicious URLs based on lexical and structural features. Its superior performance comes from its ability to handle the imbalanced nature of the used dataset. By using its class weight parameter, the RF classifier can automatically adjust the weights inversely proportional to class frequencies. In this way, the minority classes (such as ‘malware’ and ‘phishing’) will be given more importance during training. As a result, this procedure directly helps improve the low recall for those classes. Alternative imbalance handling techniques such as oversampling or synthetic data generation (e.g., SMOTE) were not applied in this study to preserve the original lexical and structural feature distributions of URLs, which could otherwise be distorted by artificial resampling.

As outlined in the proposed methodology, the constructed classifier is packaged for use in the Detection Phase. This means that the constructed classifier is serialized and stored as a .pkl file so that it can be consumed by a commercial application during the Deployment Phase [35].

5.5. Discussion and Comparison with SOTA Methods

In this subsection, the proposed NetGuard is compared with state-of-the-art probabilistic and learned filter frameworks in terms of the general contribution and the main objectives. Table 10 illustrates that the major limitation of existing solutions lies in their use of fixed-size filters that do not support dynamic environments. Although [23,24] have improved memory consumption, working with dynamic environments experiencing unexpected growth in URL size shifts the focus to reliability and dependability, making it more important than memory consumption. Memory consumption, however, remains a crucial factor given the current evolution of data and the need for optimal memory usage.

Furthermore, the rapid growth of URLs also necessitates the removal of outdated signatures. This is where the proposed framework’s key contribution lies: supporting continuous scalability by offering the HSDF, a multi-layered scaling filter that supports element deletion and efficient memory consumption compared to blacklist techniques, while maintaining an acceptable false-positive rate and high classification accuracy through integrated ML models.

As stated in Table 10, NetGuard’s architecture provides substantial memory enhancement via the HSDF. This is because the HSDF memory footprint is only 2.7 MB, which highlights that our hybrid approach yields a 99.88% memory consumption improvement over the standalone RF classifier, which demands a massive footprint of 2253.17 MB. Thus, it forms an ultra-lightweight first line of defense.

Table 10. Comparison of NetGuard with state-of-the-art probabilistic and learned filter frameworks.

Framework/Method	Filter Structure	ML Integration	Scalability (Dynamic Growth)	Deletion Support	Memory Efficiency
Nandhini, K. [22]	Standard Bloom Filter	None	No	No	Very Low
Reviriego et al. [23]	Learned Bloom Filter (LBF)	Binary Classifier	No (Fixed Size)	No	High
deepBF [24]	Learned Bloom Filter + Evolutionary DL	Deep Learning	No (Fixed Size)	No	Very High
Traditional CBF	Counting Bloom Filter	None	No	Yes	Low
SBF	Scalable Bloom Filter	None	Yes (multi-layered)	No	Medium
NetGuard (Proposed)	Hybrid Scalable Detection Filter (HSDF)	Multi-class ML (RF/DT)	Yes (multi-layered)	Yes	High (Optimized via HSDF)

Note: This table presents a structural and qualitative architectural comparison, rather than direct numeric benchmarks, due to the varying in dataset sizes, URL length distributions, hash function number, and hardware configurations for each study.

Table 10. Comparison of NetGuard with state-of-the-art probabilistic and learned filter frameworks.

Framework/Method	Filter Structure	ML Integration	Scalability (Dynamic Growth)	Deletion Support	Memory Efficiency
Nandhini, K. [22]	Standard Bloom Filter	None	No	No	Very Low
Reviriego et al. [23]	Learned Bloom Filter (LBF)	Binary Classifier	No (Fixed Size)	No	High
deepBF [24]	Learned Bloom Filter + Evolutionary DL	Deep Learning	No (Fixed Size)	No	Very High
Traditional CBF	Counting Bloom Filter	None	No	Yes	Low
SBF	Scalable Bloom Filter	None	Yes (multi-layered)	No	Medium
NetGuard (Proposed)	Hybrid Scalable Detection Filter (HSDF)	Multi-class ML (RF/DT)	Yes (multi-layered)	Yes	High (Optimized via HSDF)

Note: This table presents a structural and qualitative architectural comparison, rather than direct numeric benchmarks, due to the varying in dataset sizes, URL length distributions, hash function number, and hardware configurations for each study.

Moreover, the NetGuard classifier is evaluated using the shared benchmark ISCX-URL-2016.

Table 11. NetGuard-classifier performance breakdown across the ISCX-URL-2016 and SupURLsIdDs datasets.

Dataset	Scheme	Accuracy (%)	Recall (Phishing)
ISCX-URL-2016	5-class	97.57%	0.96
SupURLsIdDs	4-Class	96%	0.83

shows the NetGuard-classifier performance breakdown across ISCX-URL-2016 and SupURLsIdDs datasets. The comparison results prove that while the proposed classifier achieves near-perfect evaluation metrics, with an accuracy of up to 98% and phishing recall of 96%, when trained on an established, static benchmark, it addresses real-world challenges on the proposed curated SupURLsIdDs dataset. Although the proposed model achieved 0.83 phishing invocations on SupURLsIdDs, this discrepancy highlights the complex overlap in the characteristics of this dataset, reflecting the current reality of attacks where phishing and malware are blurred, resulting in complex and closely spaced boundaries. Figure 13 illustrates the confusion matrices of the NetGuard classifier on the ISCX-URL-2016 and SupURLsIdDs datasets, respectively. As shown in Figure 13a, the ISCX-URL-2016 test set contains only 2276 phishing samples, which may account for the high phishing recall (0.96) observed on this dataset. However, the SupURLsIdDs test set contains 22,180 phishing samples. The dominant failure mode, which reports a recall of 0.85, is characterized by 5407 phishing samples being cross-predicted as benign. This confirms that phishing URLs frequently utilize structural parameters that are looking clean and legitimate to hide their malicious nature.

6. Conclusions

The increasing prevalence of malicious URLs continues to threaten digital security, posing a continuous challenge to the traditional detection solutions. This paper proposes NetGuard, a novel hybrid framework that provides a scalable, adaptive and intelligent malicious URL detection mechanism. It introduces the HSDF, a novel PDS that integrates the deletion capabilities of CBF with the growth-oriented nature of the SBF. The evaluation results validate the effectiveness of the proposed framework’s modules. The experimental evaluation demonstrated that the HSDF achieves high resource efficiency, requiring minimal memory (≈ 2.7 MB for 222,000 URLs), while supporting efficient insertion/deletion operations. This was achieved while maintaining a controlled false-positive rate. Concurrently, the packaged ML classifier, built using an RF model, trained on distinctive lexical and structural URL features, attained a high overall detection accuracy of approximately 96%. This study intentionally focused on the Construction Phase (Phase 1) of the NetGuard framework, which includes the design, implementation, and analysis of the HSDF (Filter Construction Module) and the ML model (Classifier Construction Module). This focus is important to evaluate the performance of the system’s underlying architecture. The core infrastructure and foundational components required for the system’s operation are represented by Phase 1 modules. On other hand, real-time system integration, dynamic HSDF updates driven by live ML inference, and deployment in operational environments, which belong to Phase 2, are represented as a system architecture and constitute future work. Through careful verification of the underlying infrastructure in this study, the proposed framework lays a strong and scalable foundation for subsequent immediate deployment and large-scale malicious URL filtering applications.

The novelty of this work lies in the design of NetGuard as a hybrid and scalable malicious URL detection framework that goes beyond conventional single-model approaches. While many previous studies mainly emphasize predictive performance, this work focuses on combining complementary mechanisms within a unified framework to improve both detection capability and operational scalability. Therefore, the contribution of this paper is not limited to classification performance alone but also extends to providing a more practical and application-oriented cybersecurity solution for large-scale malicious URL analysis. A limitation of this work might stem from the lack of validating the HSDF update process by the ML classifier. However, the HSDF’s updateability and scalability, along with its ability to maintain a controlled false-positive rate, have been validated. The framework’s deployment (Phase 2) will involve integrating the proposed modules, which have already been validated for scalability, sustainability, and accuracy.

In addition, this integration improves the knowledge base of the NetGuard by updating the proposed HSDF and the URLs repository with newly verified malicious URLs. The successfully validated first phase serves as the essential foundation for the next stage of this research. Despite these strengths, NetGuard still has several limitations and opens promising directions for future work, including:

• Implementing the full, two-phase NetGuard framework in a live environment. This will involve deploying the “Detection Phase” to analyze real-time web traffic, integrating the HSDF and classifier for high-speed lookups, and enabling the dynamic update mechanism.
• Exploring the impact of integrating behavioral or content-based URL feature sets on the classifier’s detection capability, as well as investigating whether this integration could enhance the classifier’s ability to detect highly sophisticated or evasive malicious URLs.
• Constructing an advanced mechanism for automatic feature selection, which could decrease online feature extraction costs.
• Finding the influence of different values of the initial false-positive rates (ϵ₀) and tightening ratios (rs) on HSDF’s performance.
• Deploying the NetGuard in a distributed environment to achieve even greater scalability.