WeDIGAR: A Light-Weighted Webshell Detection Framework for Satellite and UAV Networks

Abstract

In satellite and Unmanned Aerial Vehicle (UAV) networks, detecting webshells presents unique challenges, particularly on ground station edge nodes. Large, resource-intensive detection models are not feasible as nodes have insufficient computing power and limited time for analysis. This paper introduces a novel approach for webshell detection tailored for these environments. Our method first extracts structural and semantic Information Granules (IGs) from the HTTP response bodies sent from the remote systems. Next, we construct a causal graph to identify and remove irrelevant IGs that are not linked to the webshell label. Finally, a random forest classifier is applied to the remaining, relevant IGs. This lightweight component has been empirically validated in both laboratory experiments and a simulated industrial application scenario. The results show that our method achieved an impressive accuracy rate exceeding 99% and a response time of less than 10 milliseconds for each request, significantly outperforming legacy systems based on graph convolutional networks.

1. Introduction

1.1. Context and Challenges in Satellite/UAV Edge Networks

Most contemporary businesses and critical infrastructure, including military and communication systems, are increasingly reliant on next-generation networks, such as satellite networks and Unmanned Aerial Vehicle (UAV) networks. These networks provide essential services like remote sensing, precision agriculture, and disaster response. Consequently, the significance of network security has grown exponentially. The unique nature of these networks—characterized by remote, often autonomous, and resource-constrained nodes—makes them particularly vulnerable to cyber threats. Injection attacks encompass various forms, including Cross-Site Script Attack (XSS), Structured Query Language (SQL) injection, webshells, etc. Among these attacks, webshells play a notable role that causes substantial financial losses amounting to billions of dollars each year. As a result, it becomes crucial to prioritize the mitigation of webshell attacks [1].

As a prime example of an injection attack, a webshell script is uploaded onto the server by exploiting vulnerabilities within a website. This enables the attacker to gain control over the server and carry out various operations, including file management and command execution. Essentially, the webshell script acts as a customized backdoor, offering the attacker the capability of executing arbitrary actions on the compromised website. The process of a webshell attack is visually depicted in Figure 1.

1.2. Limitations of Existing Webshell Detection Methods

Researchers have made significant contributions in the field of webshell attack detection [2]. There are three types of webshell detection models: rules-based, machine-learning-based, and hybrid methods (combining fixed rules with machine learning). For example, computing the scores of malicious signatures and malicious feature samples is a rule-based method [3], while the use of multilayer perceptrons, random forests, convolutional neural networks (CNNs), and support vector machine (SVMs) are all methods based on machine learning [4,5,6]. Although most machine-learning-based methods are supervised, sometimes supervised methods work well too [7]. In addition to these two categories, combining the features of operation code sequences with naïve Bayes [8] belongs to the hybrid type.

There are two types of analyzing methods for webshell attacks based on the object analysis. One is based on source file analysis, which extracts opcode sequence features from source files and analyzes them [9]; the other is based on HTTP traffic analysis, which analyzes traffic changes or HTTP requests [10,11].

In a scenario involving a satellite network operator or a UAV fleet management service, strict access restrictions are often enforced to protect the privacy and security of source code and sensitive data on cloud servers or edge nodes. This is especially true for systems operating in remote or hostile environments. Consequently, directly accessing source files on the satellite’s or UAV’s embedded systems, or sampling all HTTP traffic between nodes, is not feasible. The available bandwidth is often limited, and the need for real-time analysis is paramount. As a result, the only viable source of information for identifying webshell attacks will be the HTTP response body (see Figure 2), which is often relayed back to a ground station or a centralized management system.

The unique constraints imposed by relying solely on the HTML response body for webshell detection intensify the challenges of obtaining high accuracy. Fortunately, the focus can be narrowed down to effectively processing the plain (unencrypted) HTML response body in most cases, without considering the encryption or decryption of HTML responses. By concentrating efforts on analyzing and understanding the plain response body patterns, it is feasible to develop robust and efficient webshell detection solutions. The method presented in this paper specifically targets the scenario where CDN providers offer additional security services, as illustrated in Figure 3.

In cloud or edge computing environments, attackers often interact with an uploaded webshell entirely over HTTP, such as in the following:

1.

Upload Phase—The attacker exploits a file upload vulnerability to place a malicious shell.php file in a web-accessible directory:

POST /upload.php HTTP/1.1

Host: victim.example.com

Content-Type: multipart/form-data;

boundary=----abcd

Content-Length: 532

• ------abcd
  Content-Disposition: form-data;
  name="file"; filename="shell.php"
  Content-Type: application/x-php

• <?php if(isset($_REQUEST[’cmd’]))
  { system($_REQUEST[’cmd’]); } ?>
  ------abcd--

2.

Command Execution Phase—Once the webshell is in place, the attacker issues commands via crafted HTTP requests, such as, for example,

• GET /uploads/shell.php?
  cmd=cat+/etc/passwd HTTP/1.1
  Host: victim.example.com

• The HTML response body returned to the client contains the command output, often wrapped in simple HTML formatting such as <pre> tags, making it appear as part of a normal page.

3.

Ongoing Interaction—By repeatedly sending HTTP requests with different cmd parameters, the attacker can perform file management, database queries, and other arbitrary actions.

This type of attack is especially relevant in Content Delivery Network (CDN) or edge-node scenarios because the detection system cannot scan source files directly. Instead, it must rely solely on analysis of the returned Hypertext Transfer Protocol (HTTP) response body to identify potential threats.

Within this particular context, the algorithm design is subject to specific restrictions and requirements. These constraints may arise due to factors such as limited computational resources, the need for real-time analysis, or compliance with industry standards and regulations. First of all, to ensure the privacy and security of customers, the data stored in the cloud cannot be scanned in the process of detecting webshells. The appropriate data available is the Hypertext Markup Language (HTML) body.

Second, we want to ensure the accuracy of identifying attacks. As a cloud service provider, the number of requests that need to be processed every day is a huge number (up to millions). Under such a large number of processing times, an error rate of 1% means that tens of thousands of requests are incorrectly classified.

Finally, the detection model should be light-weighted and efficient enough. If the time taken to identify a webshell attack is too long, the customer experience will be poor, so the time taken to identify a webshell attack should be as short as possible. In addition, the computing ability of edge nodes is not as strong as that of a computing work station.

1.3. Our Approach and Main Contributions

To fulfill these requirements in satellite/UAV edge networks, we propose WeDIGAR (Webshell Detecting system based on Information Granules Analysis of HTML Response), a novel, light-weighted framework. We focus on optimizing every stage of the pipeline to minimize resource usage while maximizing detection accuracy. Our main contributions are summarized as follows:

• Novel Information Granule (IG) Extraction and Causal Selection: We design a specialized feature engineering method utilizing only the HTTP response bodies and introduce the Non-combinatorial Optimization via Trace Exponential and Augmented lagRangian for Structure learning (NOTEARS) causal graph learning algorithm. This approach identifies the minimal set of causally relevant IGs, eliminating spurious correlations to maximize model robustness and efficiency for resource-constrained nodes.
• Superior, Light-Weighted Performance: The resulting framework achieves high performance metrics essential for high-throughput environments, exhibiting high accuracy (⩾99%) and a high $F_1$ score (⩾99% for webshell recognition), while remaining fast enough (detection time of each sample ⩽10 ms on edge nodes) to support the timely online identification of webshell attacks.
• Dataset Contribution: To enhance research on webshell detection based on HTTP responses, we release the comprehensive experimental dataset, which consists of 250,321 training and 360,000 test samples, providing a valuable resource for the security community.

1.4. Paper Organization

The organization of this paper is as follows: Section 2 introduces the related works of this method. Section 3 introduces the details of the causal learning algorithm used in the model. The detailed implementation of WeDIGAR is presented in Section 4, and the datasets, experiments, and $\beta$-testing are reported in Section 5. Section 6 provides a brief summary of this paper.

2. Related Works

Currently, there are multiple approaches available for detecting webshells, which can be divided into two categories based on the objective used for investigation. The first category is to identify webshell attacks by analyzing web page source files (such as PHP, aspx, etc.), while the second category focuses on analyzing HTTP traffic to detect webshell attacks. Figure 4 illustrates the techniques for webshell detection, and the methods described below are mostly a combination of the approaches depicted in the figure.

2.1. Based on Source File

Among the various methods for detecting webshell attacks, analyzing source files is the most widely used approach. These methods can be further categorized into two main types: rule-based methods and learning-based methods.

Most of the rule-based methods are based on the understanding of webshell scripts to formulate rules, or combined with some statistical methods. Among them, an early webshell detection system is built by computing the scores of malicious signatures and malicious feature samples [3]. Deng et al. provided detailed lexical analysis of webshell scripts that provides a large amount of convenience for subsequent detection [12]. A static webshell detection method based on taint analysis (Webshell Taint Analysis, WTA) traces the spread of taint variables, conducts inter-procedural analysis on them, and finally makes webshell identification based on the invocation of dangerous functions and the references to taint variables [13].

Learning-based methods are slightly more popular than rule-based methods. Most learning-based methods need to extract and process features first and then make judgments through classification models. A simple method is to directly analyze the webshell interface, extract features, and then analyze the results via matrix decomposition [14]. Alternatively, one can extract features via pattern matching techniques and then apply a Convolutional Neural Network (CNN) for prediction [15].

However, this feature extraction method relies heavily on prior knowledge. A more common practice is to apply some machine learning algorithms to learn or transform features first, and to then make classification. In this way, the problems caused by manual selection of features can be avoided and the performance of the algorithm can be improved. For example, the words in the PHP source file can be vectorized by Word2vec first, and then the Gated Recurrent Unit (GRU) and attention mechanism can be used to check the webshell attack [16]. Recently, a similar approach has been proposed to target a variety of other formats, such as Java Server Pages (JSP), Active Server Pages eXtended (ASPX), and Active Server Pages (ASP) [17]. It is also an effective method to apply Term Frequency–Inverse Document Frequency (TF-IDF) to calculate the word frequency matrix. After obtaining the word frequency matrix, the model only needs to add a multilayer perceptron to find out the webshell [6].

Ensemble learning is also commonly used to improve models for webshell detection. WS-LSMR integrates logistic regression, a Support Vector Machine (SVM), a multilayer perceptron, and a random forest [18]. This method has higher accuracy than a single model. In addition, it is also necessary to decide whether a model needs to be integrated according to the application scenario. Through simulation experiments, Yong et al. found that, in the scenario of lightweight Internet of Things (IoT) devices (such as smart phones, headsets), using random forests and extremely random trees alone will have better results, while, for heavyweight IoT scenarios (consisting of computers or servers, etc.), the ensemble model performs better [19].

During surveying related works, we found the decision trees and random forests that are the most commonly used. They are a decision tree based on an expert system [20], the combination of FastText and a random forest [4], and a Random Forest–Gradient Boosting Decision Tree (RF-GBDT) that combines a random forest and GBDT classifier [9]. Researchers continue to combine random forests with different algorithms to generate new models, and the excellent performance of these models fully illustrates the potential of the random forest algorithm.

There are also methods that combine rule-based matching methods with learning-based methods, for example, first matching the opcode sequence and then training a naive Bayes classifier for classification [8]. Compared with the rule-based detection method, the recognition accuracy and efficiency of this model are greatly improved.

To provide a clearer overview of the research landscape and to precisely position our contribution, we summarize the main categories of webshell detection methods in

Table 1. Comparative summary of webshell detection approaches.

Category	Core Methodology	Representative Works	Key Features	Limitations
Rule-based Source File Analysis	Malicious signature matching, static taint analysis.	[3,12,13]	Relies on manually defined rules; effective against known patterns.	Cannot detect obfuscated/encrypted webshells; high false-positive rate; rules require frequent updates.
ML-based Source File Analysis	Extracts features (e.g., TF-IDF, opcode sequences) and uses classifiers like RF, SVM.	[4,9,19]	Reduces reliance on manual rules; better generalization than pure rule-based methods.	Requires full source code access; feature engineering is complex; high computational cost.
Deep Learning Source File Analysis	Uses CNN, LSTM, GRU with attention to automatically learn features from source code.	[15,16,17]	End-to-end feature learning; robust against code obfuscation.	Demands large labeled datasets; high computational overhead; unsuitable for real-time detection on edge devices.
Traffic Analysis Methods	Monitors HTTP request/response patterns using CNN, LSTM, or SVM.	[5,10,11]	No need for source file access; can detect in-memory webshells.	Requires full traffic capture and session reconstruction; performance degrades with encrypted traffic.
Hybrid and Ensemble Methods	Combines rules, ML, and DL models to improve detection coverage and robustness.	[8,18,21]	High accuracy (up to 98%+); leverages strengths of multiple approaches.	High system complexity and resource consumption (e.g., >16 GB RAM); not feasible for resource-constrained environments.
Our WeDIGAR Framework	IGs + Causal Learning + RF. Analyzes only HTML response body using structural/semantic IGs, NOTEARS for feature selection, and a lightweight RF.	This work	No source file access needed; lightweight and fast (≤10 ms); high accuracy (≥99%) and suitable for edge nodes.	Currently cannot detect encrypted webshells (to be addressed in future work).

. The table compares existing approaches based on their core methodology, key features, and inherent limitations. As the comparison elucidates, the majority of methods either require access to server source files or full HTTP traffic, which is infeasible in our target scenario of resource-constrained, privacy-sensitive edge nodes. In contrast, our proposed WeDIGAR framework is uniquely designed to operate solely on the HTML response body, leveraging a novel pipeline of information granulation and causal learning to achieve a lightweight yet highly accurate detection suitable for immediate deployment in satellite and UAV ground stations.

2.2. Based on HTTP Traffic

Compared with the analysis method based on source files, the analysis method based on HTTP traffic is less used, mainly because the data is less informative for webshell detection while being more difficult to collect.

Tian et al. proposed a webshell attack detection method based on Word2vec representation and a Convolutional Neural Network (CNN), which is the first time that a CNN is applied to webshell detection [5]. After that, many researchers began to introduce CNNs into webshell detection. For example, by using CNNs and Long Short-Term Memory (LSTM) to monitor request and response traffic, it is possible to quickly discover abnormal behaviors and detect the existence of webshell scripts [11]. In addition to CNNs, the classic SVM can also be applied in the field of traffic analysis. Yang et al. proposed an attack detection technology based on an SVM algorithm to locate the webshell attack in HTTP traffic [10].

In addition to the above methods that directly analyze HTTP traffic, there are also methods that try to restore web sessions and extract features from the sequence of HTTP requests for analysis. For example, a webshell detection framework was built using long LSTM and Hidden Markov Models (HMMs) to extract features from the raw sequence data of web logs [21]. This method is more efficient than those based on source files but requires restoring sessions as a data source. Thus, this method cannot meet the requirement of real-time analysis.

These methods based on HTTP traffic analysis mainly depend on traffic changes, but the application scenario on edge computing nodes of a CDN provider only allows one to analyze the HTML response due to the computing capability and real-time discrimination constraint. Therefore, the aforementioned methods are not directly applicable.

3. Causal Learning with NOTEARS

Feature selection is an ordinary methodology used to reduce the dimension of data and improve the classification performance [22]. However, we believe that the causal relation between features is more powerful than correlation in webshell detection. Zheng et al. proposed Non-combinatorial Optimization via Trace Exponential and Augmented lagRangian for Structure learning (NOTEARS) in 2018 [23]. NOTEARS transforms the structural learning problem from combinatorial optimization into purely continuous optimization, and thus can be solved directly by standard numerical algorithms. The graph structure learned by this algorithm can not only be used as the graph structure for the graph convolution network but can also be used for causal reasoning. Compared with the classical Peter–Clark (PC) algorithm [24], NOTEARS results in higher accuracies in downstream WeDIGAR classification.

NOTEARS is a non-combinatorial optimization-based causal graph learning method particularly suitable for capturing causal relationships between features. Unlike traditional correlation-based methods, NOTEARS does not only focus on the correlations between features but also constructs a Directed Acyclic Graph (DAG) that explicitly represents causal relationships between features. Specifically, NOTEARS optimizes the structure learning problem and automatically discovers which features have a direct or indirect influence on the target variable (whether a webshell attack occurs).

In webshell detection tasks, the relationship between features and labels is not always simple or linear. For example, some features within HTML tags (such as content in the script tag) might directly affect the detection of a webshell, while other seemingly unrelated features (such as text in a div tag) might not have a direct relationship with the attack label. By using NOTEARS for causal graph learning, we can automatically identify which features are crucial in the decision-making process, thereby improving classification performance and interpretability.

Generally, the causal relationship between features can be encoded by a directed acyclic graph W. NOTEARS follows the Structural Equation Model (SEM), which assumes that each feature $X_j$ in a sample X can be constructed via $X_j=w_j^{\top }X+z_j$, where $w_j$ is the jth column vector of W and $z_j$ is a constant.

NOTEARS formulates the objective function as Equation (1) by comparing X with X reconstructed by W, with a regularization term encouraging sparse edges [23].

$$\begin{array}{cc}\hfill F\left(W\right)& =\ell (W;X)+{\lambda \parallel W\parallel }_1\hfill \\ \hfill & ={\displaystyle \frac{1}{2n}}{\parallel X-XW\parallel }_F^2+\lambda {\parallel W\parallel }_1,\hfill \end{array}$$

(1)

where $\lambda$ is the regularization parameter.

To obtain the graph structure that best describes the feature relationship, one needs to solve the following constrained optimization problem [23]:

$$\begin{array}{cc}\hfill \underset{W\in {\mathbb{R}}^{d\times d}}{min}& F\left(x\right)\hfill \\ \hfill subjectto& G\left(W\right)\in \mathbb{D},\hfill \end{array}$$

(2)

where $G\left(W\right)\in \mathbb{D}$ is the constraint on the graph structure W; that is, W should be a directed acyclic graph. NOTEARS converts combinatorial acyclic constraints into continuous equality constraints, as shown in Equation (3), in which $h(·)$ is a continuous function. The minimum value of $F\left(W\right)$ can be found directly by standard numerical algorithms under the constraints of continuous equality.

$$\begin{array}{c}\begin{array}{cc}\hfill \underset{W\in {\mathbb{R}}^{d\times d}}{min}& F\left(x\right)\hfill \\ \hfill subjectto& G\left(W\right)\in \mathbb{D}\hfill \end{array}\end{array}⟺\begin{array}{c}\begin{array}{cc}\hfill \underset{W\in {\mathbb{R}}^{d\times d}}{min}& F\left(x\right)\hfill \\ \hfill subjectto& h\left(W\right)=0\hfill \end{array}\end{array}$$

(3)

For this equality-constrained programming problem, NOTEARS is mainly divided into three steps:

(1)

Transform the constrained problem into a series of unconstrained subproblems by augmenting Lagrangian;

(2)

Solve the unconstrained subproblem by the L-BFGS (Limited-memory Broyden–Fletcher-Goldfarb–Shanno) algorithm [25];

(3)

Take a reasonable threshold.

The overall time complexity of the L-BFGS update in NOTEARS is $O\left(m^2\right|\mathcal{S}|+m^3+m|\mathcal{S}\left|T\right)$, where m is the size of the memory, $\left|\mathcal{S}\right|$ is the size of the active set, and T is the number of inner iterations [23].

4. WeDIGAR Model

WeDIGAR consists of three main stages. The first is information granule construction, which transforms the original HTML response body ${\mathcal{D}}_{raw}$ into ${\mathcal{D}}_{integ}$ by integrating structural and semantic Information Granules (IGs) of the HTML response body. Secondly, the information granules of ${\mathcal{D}}_{integ}$ are selected by using a Directed Acyclic Graph (DAG) learned by NOTEARS; that is, the information granules that cannot reach the class label in the DAG will be excluded. The information granule selection operation transforms ${\mathcal{D}}_{integ}$ into ${\mathcal{D}}_{final}$. Finally, a random forest is used for classification to obtain the webshell detection result. The architecture of WeDIGAR is shown in Figure 5.

Since the random forest [26] is a well-known classifier, we focus on the construction of information granules and information granule selection here.

4.1. Information Granule Construction

Prior to training the model, it is crucial to extract meaningful IGs from the HTML response. The IGs contained within the HTML response can be categorized into two distinct parts: structural information granules and semantic information granules.

Structural information granules pertain to the presence of tags within an HTML response. These tags present the overall structure of an HTML document, so they are referred to as structural information granules. Semantic information granules, on the other hand, encompass the details embedded within the tags, such as text, scripts, and content in other forms. By combining both structural and semantic IGs, we can comprehensively represent the information encapsulated within an HTML response. The details of how to construct structural and semantic IGs from an HTML response is given below.

4.1.1. Structural Information Granules

The HTML response body is a semi-structural document. Therefore, instead of treating the response body as a plain text file, it is more appropriate to segment it based on the tags and construct structural IGs.

During the structural IG construction phase, it is crucial to consider all possible tags and their associated attributes. Subsequently, these structural IGs should be refined and adjusted based on prior knowledge and the distribution of the dataset. The process is illustrated in the right part of Figure 5.

Therefore, the HTML response body is firstly segmented according to the tag using Regular Expression (RE) matching, and different structural IG construction methods are applied to different tags. For some tags, in addition to recording the attribute information attached to the tag, the information carried by the nested text or script is also recorded. After analysis, we construct the initial structural IGs $F_{init}$. In this way, dataset ${\mathcal{D}}_{raw}$ is transformed into ${\mathcal{D}}_{init}$.

Then, according to the prior knowledge, the structural IGs that are completely irrelevant to webshell recognition (e.g., the font size, font color, etc.) will be removed. After removing this part of structural IGs from $F_{init}$, we obtain new structural IGs $F_{temp}$. Accordingly, the subset of the dataset ${\mathcal{D}}_{init}$ corresponding to these structural IGs $F_{temp}$ is changed into ${\mathcal{D}}_{temp}$.

Finally, the structural IGs are filtered based on frequency to remove non-discriminatory features. Specifically, the following is carried out:

• Cardinality-One Filter (Too Common): Structural IGs with a cardinality of one (the same value on more than 99% of all samples in the dataset $D_{temp}$) are removed. These are non-discriminatory background features that do not contribute to classification.
• Never-Appeared Filter (Too Rare): Structural IGs that appear in fewer than five samples in $D_{temp}$ are removed. These extremely sparse features introduce noise and increase model complexity without statistical significance.

In this way, $F_{struc}$ is derived from $F_{temp}$ and the dataset is transformed into $D_{struc}$. The $F_{struc}$ fully describes the structural IGs contained in the HTML response.

4.1.2. Semantic Information Granules

Alongside the structural IGs, the semantic content in the HTML response plays an important role in webshell detection. This paper utilizes the Term Frequency times Inverse Document Frequency (TF-IDF) index [27] to extract the semantic IGs from the HTML tags. The steps are as follows:

First, the information granule transformer $\mathcal{T}$ using the TF-IDF algorithm is trained on all the samples in ${\mathcal{D}}_{raw}$. The use of TF-IDF serves as the initial step to down-weight general, high-frequency words that appear across the entire dataset.

Next, to isolate keywords that are specifically indicative of webshell activity, we perform class-specific filtering based on the frequency distribution of words between the positive and negative sample sets. We use $\mathcal{T}$ to count the keyword sets in the positive samples and negative samples to obtain the positive sample keyword set $S_{pos}$, and the negative sample keyword set $S_{neg}$. While TF-IDF effectively reduces overall noise, certain non-malicious words remain that are highly frequent specifically within the negative (normal traffic) samples ($S_{neg}$). These terms are not discriminatory and must be explicitly removed to prevent the model from learning spurious correlations based on benign patterns.

To achieve this targeted filtering, we define a function $top(·,·)$ as shown in Equation (4). This function sorts the elements in the collection according to the frequency of occurrence from high to low.

$$\begin{array}{cc}\hfill top(1,S)& =\left\{\stackrel{Sortedby\mathrm{TF}-\mathrm{IDF}value}{\overbrace{s_{\left(1\right)},s_{\left(2\right)},\dots ,s_{\left(i\right)},\dots ,s_{\left(n\right)}}}\right\}\hfill \\ \hfill top({\displaystyle \frac{1}{\rho }},S)& =\left\{s_{\left(1\right)},s_{\left(2\right)},\dots ,s_{(\lfloor n/\rho \rfloor )}\right\},\hfill \end{array}$$

(4)

in which S is the word set appearing in the HTML response [27] and $s_i$ is the ith keyword in the word set ranked by its TF-IDF value.

Next, $S_{pos}$ is subtracted by the top $1/3$ of the most frequent words in negative samples (this operation performs a targeted, class-specific pruning of high-frequency normal terms in $S_{neg}$ that survived the initial TF-IDF weighting). The difference set is used as the final webshell-sensitive word set $S_{sens}$. The $1/3$ heuristic was empirically chosen to provide the optimal balance for pruning common, non-discriminatory background words while retaining potentially weak, but discriminatory, malicious keywords. This insensitive word filtering operation can be formulated as

$$S_{sens}=S_{pos}\setminus S_{neg}.$$

(5)

Finally, the m items with the highest frequency in $S_{sens}$ are evenly divided into k groups as the semantic IGs $F_{sem}$. This grouping process serves as a dimensionality reduction technique, converting m highly sparse features into k denser, abstract features, which improves the computational efficiency and robustness of the downstream classifier. The value of k was determined via cross-validation to optimize the balance between feature representation and model efficiency (specific value detailed in Section 5.1). For each semantic information granule in $F_{sem}$, we record the number of occurrences of its in-group keywords in the sample. Similarly, we can obtain ${\mathcal{D}}_{sem}$ from $F_{sem}$. $F_{sem}$ describes the semantic IGs contained in the HTML response body. Combining $F_{sem}$ with $F_{struc}$, an integrated IGs $F_{integ}$ is obtained to fully describe the HTML response. Likewise, we obtain ${\mathcal{D}}_{integ}$ from ${\mathcal{D}}_{raw}$ by constructing the IGs $F_{integ}$ from raw HTML responses.

4.2. Information Granule Selection

The IGs $F_{integ}$ fully represents the original data ${\mathcal{D}}_{raw}$. However, some IGs in $F_{integ}$ may not have correlation with the target attribute (i.e., the label). Therefore, it is necessary to determine which IGs are truly relevant to the label and to ensure that the detection model os efficient and accurate.

We choose the NOTEARS algorithm to construct a causal graph $\mathbb{G}$ based on ${\mathcal{D}}_{integ}$ and the corresponding label, as shown in Equation (6). The function $cat(·,·)$ in the formula concatenates ${\mathcal{D}}_{integ}$ with its corresponding labels. If there is a directed edge from a to b in the causal graph $\mathbb{G}$, then information granule b is a conditional dependent on information granule b.

$$\mathbb{G}(\mathbb{V},\mathbb{E})=NOTEARS\left(cat({\mathcal{D}}_{integ},label)\right)$$

(6)

Through the learned causal graph $\mathbb{G}$, one can delete the nodes that are not correlated to the label y, which is formulated as

$$F_{final}\leftarrow F_{integ}\setminus \left\{f\right|f\in F_{integ}\wedge f\stackrel{\mathbb{E}}{\nrightarrow }y\},$$

(7)

in which $f\stackrel{\mathbb{E}}{\nrightarrow }y$ means that there is no path from node f to node y given the directed edge set $\mathbb{E}$. In this way, the final IGs $F_{final}$ and corresponding dataset ${\mathcal{D}}_{final}$ are constructed.

4.3. Algorithm Description of WeDIGAR

In this section, we give an algorithmic description of the WeDIGAR method. The training phase of WeDIGAR is shown in Algorithm 1 and the testing phase in Algorithm 2.

Algorithm 1 Training phase of WeDIGAR

Require:  Raw training dataset ${\mathcal{D}}_{raw}$ with labels $\mathit{y}$ Ensure:  Final IG set $F_{final}$; Trained classifier $RF\left(x\right)$ Step 1: Information Granules Construction 1: $[F_{init},{\mathcal{D}}_{init}]\leftarrow \mathrm{REM}\left({\mathcal{D}}_{raw}\right)$ 2: $F_{struc}\leftarrow \mathrm{RemoveOneValue}\left(\mathrm{RemoveIrrelavant}\left(F_{init}\right)\right)$ 3: $S_{pos}\leftarrow \mathrm{top}(1,\{s\in {\mathcal{D}}_{raw}\mid y=1\})$ 4: $S_{neg}\leftarrow \mathrm{top}({\displaystyle \frac{1}{3}},\{s\in {\mathcal{D}}_{raw}\mid y=0\})$ 5: $S_{sens}\leftarrow \mathrm{top}({\displaystyle \frac{m}{M}},S_{pos}\setminus S_{neg})$ 6: Partition $S_{sens}$ into k equal subsets ${\left\{S_{sens}^{\left(i\right)}\right\}}_{i=1}^k$ 7: $F_{sem}\leftarrow S_{sens}^{\left(1\right)}\circ \cdots \circ S_{sens}^{\left(k\right)}$ 8: $F_{integ}\leftarrow F_{struc}\circ F_{sem}$ Step 2: Information Granules Selection 9: $\mathbb{G}(\mathbb{V},\mathbb{E})\leftarrow \mathrm{NOTEARS}\left(\mathrm{cat}({\mathcal{D}}_{integ},\mathit{y})\right)$ 10: $F_{final}\leftarrow \{f\in F_{integ}\mid f\stackrel{\mathbb{E}}{\to }y\}$ Step 3: Classifier Training 11: ${\mathcal{D}}_{final}\leftarrow \mathcal{E}({\mathcal{D}}_{init},F_{final})$ 12: Train $RF\left(x\right)$ using $({\mathcal{D}}_{final},\mathit{y})$ 13: return $F_{final}$, $RF\left(x\right)$

In Algorithm 1, function $REM\left({\mathcal{D}}_{raw}\right)$ means to perform a Regular Expression Matching (REM) operation on dataset ${\mathcal{D}}_{raw}$ to obtain structural IGs $F_{init}$. The definitions of functions $RemoveIrrelavant(·)$ and $RemoveOneValue(·)$ are explained previously (in Section 4.1.1). The operator ∘ concatenates two row vectors.

In Algorithm 2, the function $\mathcal{R}(\tilde{\mathcal{D}},F)$ reduces the dataset $\tilde{\mathcal{D}}$ to only include the IGs of F, and the function $\mathcal{F}(\tilde{\mathcal{D}},F_{sem}$ finds the total frequency of the words in each group of $F_{sem}$ from dataset ${\tilde{\mathcal{D}}}_{raw}$ and forms new dataset ${\tilde{\mathcal{D}}}_{sem}$. The operator ◯ merges two datasets by concatenating each row of the same index.

Algorithm 2 Testing phase of WeDIGAR

Require:  Test dataset ${\tilde{\mathcal{D}}}_{raw}$; Final IG set $F_{final}$; $F_{struc}$; $F_{sem}$ Ensure:  Predicted labels $\widehat{\mathit{y}}$ Step 1: Feature Extraction 1: ${\tilde{\mathcal{D}}}_{struc}\leftarrow \mathcal{E}({\tilde{\mathcal{D}}}_{raw},F_{final}\cap F_{struc})$ 2: ${\tilde{\mathcal{D}}}_{sem}\leftarrow \mathcal{E}({\tilde{\mathcal{D}}}_{raw},F_{final}\cap F_{sem})$ Step 2: Feature Integration 3: ${\tilde{\mathcal{D}}}_{final}\leftarrow {\tilde{\mathcal{D}}}_{struc}\circ {\tilde{\mathcal{D}}}_{sem}$ Step 3: Prediction 4: $\widehat{\mathit{y}}\leftarrow RF\left({\tilde{\mathcal{D}}}_{final}\right)$ 5: return  $\widehat{\mathit{y}}$

4.4. Time and Space Complexity

4.4.1. Time Complexity

Training Phase. Computing the structure IGs $F_{struc}$ for each sample cost $O\left(L\right)$, so, for the dataset, $O(N\times max(L)$, where L represents the text length of the HTML response body and N is the size of training set. Using TF-IDF to extract sensitive words needs to traverse the entire training set, hence the time complexity of $O(N\times S)$, where S is the size of possible sensitive words. In addition, the time complexity of training the random forest is $O(d\times T\times N\times logN)$, where d is the number of IGs and T is the number of decision trees. Therefore, apart from NOTEARS (whose complexity is introduced at the end of Section 3), the time complexity for training WeDIGAR is $O(N\times (L+S+d\times T\times logN\left)\right)$.

Testing Phase. Extracting $F_{struc}$ in testing is the same as in training, but computing $F_{sem}$ is much faster than in training because the frequency of each considered sensitive word is ready to be used. Furthermore, random forest complexity in testing is $O(H\times T)$, where p is the height of the decision tree, which is much more efficient than in training. So the overall time complexity for WeDIGAR testing a sample is $O(L+H\times T)$, which is completely suitable for online deployment.

4.4.2. Space Complexity

During the information granule construction phase, structural IGs are obtained using regular expression matching. As the process is solely based on rule matching, the space complexity of information granule construction for a single sample is $O\left(1\right)$. The space complexity of a random forest is generally $O(q\ast T)$, where q is the number of nodes in the subtree and T is the number of subtrees. To sum up, the space complexity of a single-sample prediction is $O(q\ast T)$, which occupies a small space. The low space requirement facilitates the online deployment of WeDIGAR on edge computing nodes.

5. Experiments and Application

5.1. Experiment Setting

The experiment was conducted on a workstation equipped with an Intel i9-10900X CPU, 64 GB RAM, running Windows 11 64-bit OS, and utilizing the Python 3.6 programming environment. The dataset used in the experiment was collected by Guizhou BaishanCloud Technology Co., Ltd. (Guizhou, China) during the operation of their Web Application Firewall (WAF). It consists of 9114 webshell samples and 241,207 normal samples.

For the training set, we randomly selected 4000 webshell attack samples and 100,000 normal samples. The remaining samples were allocated as the test set. The test set was further divided equally into $datase{t}_1$ and $datase{t}_2$, and the model was evaluated separately on both datasets.

To ensure a fair and reproducible evaluation, the WeDIGAR framework utilized the following hyper-parameter settings, which were optimized using 5-fold cross-validation on the training set:

Random Forest: Number of trees ($N_{tree}$) = 100, maximum depth ($D_{max}$) = none (allowing for full growth).

NOTEARS: Regularization parameter ($\lambda$) = 0.01 (optimized for sparsity).

Structural IG Filtering: Minimum frequency threshold = 5 samples, maximum frequency threshold = 99

Semantic IG Grouping (k): The total number of high-frequency sensitive words (m) was aggregated into $k=50$ groups. This value was empirically selected as it provided the optimal trade-off between dimensionality reduction and the model’s F1-score performance, significantly reducing the feature space from over m features to 50, which is critical for light-weighted deployment on edge nodes.

Due to the stochastic nature of machine learning methods, each method was tested 10 times, and the average performance was calculated. Additionally, the deviation value was computed based on these results. Since many of the methods discussed in the related work cannot be directly applied to HTML response body analysis, most of the methods compared in this section were designed by our own team. A few methods were sourced from a pending update module in a cloud service provider’s WAF.

5.2. Metrics

In binary classification problems, there are four indices to consider, namely True Positives (TPs), True Negatives (TNs), False Positives (FPs), and False Negatives (FNs). Based on these four indices, the metrics of recall, precision, and accuracy are defined in Equation (8) [27].

$$\begin{array}{cc}\hfill Precision& ={\displaystyle \frac{\mathrm{TP}}{\mathrm{TP}+\mathrm{FP}}}\hfill \\ \hfill Recall& ={\displaystyle \frac{\mathrm{TP}}{\mathrm{TP}+\mathrm{FN}}}\hfill \\ \hfill Accuracy& ={\displaystyle \frac{\mathrm{TP}+\mathrm{TN}}{\mathrm{TP}+\mathrm{FP}+\mathrm{TN}+\mathrm{FN}}}\hfill \end{array}$$

(8)

$Precision$ describes the accuracy of the model in identifying true positive samples, while $recall$ represents the model’s ability to identify as many positive samples as possible. Because $precision$ and $recall$ are negatively correlated metrics and accuracy favors the major class in imbalanced classification, $F_1$ score (defined in Equation (9)) is a more balanced metric for evaluation [27]:

$$F_1=2\ast {\displaystyle \frac{Precision\ast Recall}{Precision+Recall}}$$

(9)

5.3. Comparison of Different Causal Analysis Methods

In this section, we compare different approaches to causal analysis. In addition to the NOTEARS algorithm included in WeDIGAR, there is the algorithm mentioned in [28], which is a generalization of NOTEARS on nonlinearity, and thus abbreviated as ${\mathrm{NOTEARS}}_{\mathrm{nolinear}}$. There is also the classic Peter–Clark (PC) [24] algorithm in causal analysis. We also run an ablated WeDIGAR model (without a causal analysis component) in the experiment.

Before the experiment, we can observe the causal graphs generated by the different algorithms (as shown in Figure 6). It can be seen that the graph generated by PC is obviously sparser than the graph generated by NOTEARS. In addition, the causal graph generated by the ${\mathrm{NOTEARS}}_{\mathrm{nolinear}}$ algorithm has the least number of blue points.

Table 2. Comparison of different causal analysis methods.

Method	Dataset 1		Dataset 2
	Accuracy (%)	F1 Score (%)	Accuracy (%)	F1 Score (%)
RF	99.95 ± 0.02	99.23 ± 0.20	99.95 ± 0.02	99.23 ± 0.10
PC + RF	99.94 ± 0.02	99.29 ± 0.15	99.94 ± 0.02	99.29 ± 0.15
Nonlinear + RF	99.93 ± 0.02	99.12 ± 0.20	99.94 ± 0.01	99.24 ± 0.10
WeDIGAR *	99.95 ± 0.01	99.35 ± 0.10	99.95 ± 0.01	99.35 ± 0.10

* Our proposed method.

presents the accuracy and $F_1$ score of various causal analysis methods used on the dataset. It can be observed that there is not a significant difference in terms of accuracy among the methods. WeDIGAR and RF achieve the same accuracy, but WeDIGAR exhibits slightly higher stability. Meanwhile, WeDIGAR demonstrates an improved $F_1$ score compared to RF, indicating that causal analysis has a positive impact on the classification results. This suggests that incorporating causal analysis techniques can enhance the overall performance of the model.

5.4. Comparison with Baseline Methods

We compare the performance of WeDIGAR against several established and state-of-the-art webshell detection methods from the literature. These baselines represent diverse approaches to feature extraction and modeling, allowing us to validate the efficacy and light-weighted advantage of our Information Granules (IGs) and causal graph approach. We adapted these models to operate on the HTTP response body to ensure a fair comparison within our target scenario.

• TF-IDF + Support Vector Machine (SVM): This classic approach represents general, high-accuracy text classification [27]. We extract standard Term Frequency–Inverse Document Frequency (TF-IDF) vectors from the full text of the response body, and the resulting high-dimensional vector is classified using an SVM. This serves as a benchmark for traditional semantic analysis.
• Convolutional Neural Network (CNN): Representing advanced deep learning approaches [16], we implemented a 1D-CNN architecture commonly used for text classification. The input tokens are first mapped to embeddings, which the CNN then uses to automatically extract high-level semantic features. This model tests the hypothesis that deep learning feature engineering can outperform our targeted IGs.
• Ensemble Model (Traffic Analysis Adapted): Based on the hybrid approaches used in high-traffic environments [8], we adapted a widely used model that combines statistical features (e.g., word count entropy, average word length) and basic content matching. This baseline assesses the value of deep linguistic features compared to broad statistical traffic metadata.

The performance comparison of WeDIGAR against these baselines is presented in

Table 3. Overall performance comparison with external comparative baselines.

Method	Dataset 1			Dataset 2
	Accuracy (%)	F1 Score (%)	Time (ms)	Accuracy (%)	F1 Score (%)	Time (ms)
TF-IDF + SVM	99.51	97.42	4.15 ± 0.50	99.54	97.58	4.19 ± 0.30
CNN	99.65	98.11	14.22 ± 1.50	99.68	98.25	14.10 ± 1.30
Ensemble Model	99.70	98.35	10.50 ± 0.80	99.71	98.40	10.60 ± 0.70
WeDIGAR *	99.95 ± 0.01	99.35 ± 0.10	4.80 ± 1.00	99.95 ± 0.01	99.35 ± 0.10	4.80 ± 1.00

* Our proposed method.

.

Table 3 clearly validates the superior performance of the proposed WeDIGAR framework against all comparative baselines, consistently achieving the highest accuracy ($99.95\%$) and $F_1$ score ($99.35\%$) across both datasets. This performance significantly surpasses the comparison models—including the statistical benchmark (TF-IDF + SVM) and the deep learning approach (CNN), which reached a maximum $F_1$ score of approximately $98.35\%$. This superior efficacy is attributed to the combined strength of structural and semantic Information Granules (IGs) and the NOTEARS causal graph selection, which effectively captures precise malicious patterns and eliminates spurious correlations common in raw HTML data. Critically, WeDIGAR achieves the optimal balance required for light-weighted edge node deployment. While the high-accuracy ensemble models incur significant latency (≈$10\mathrm{ms}$ to $14\mathrm{ms}$), and the fastest model (TF-IDF + SVM) has a significantly lower $F_1$ score that compromises security, WeDIGAR maintains its leading performance profile while operating with a rapid inference time of $4.80\pm 1.00\mathrm{ms}$.

5.5. Comparison of Different Methods with Same $F_{final}$

We compare different classification methods using the identical, causally selected feature set, $F_{final}$. These methods include classical machine learning algorithms such as KNN and SVMs, as well as Graph Convolutional Network (GCN) variants. Since GCNs require an input feature matrix $\mathbf{X}$ (which is ${\mathcal{D}}_{final}$ in our case) and an adjacency matrix $\mathbf{A}$ representing the structure, we test different methods for generating $\mathbf{A}$ from $F_{final}$. The general GCN architecture used is based on [29].

We define the GCN baselines based on their graph construction method:

• ${\mathbf{GCN}}_{\mathbf{\text{euclid}}}$ [29]: The adjacency matrix $\mathbf{A}$ is constructed based on the Euclidean distance (similarity) between the samples in ${\mathcal{D}}_{final}$. Specifically, we use the k-nearest neighbors ($\mathrm{k}=5$) graph construction method, which is a common practice for GCNs when a graph structure is not explicitly defined. This variant relies on inherent feature similarity.
• ${\mathbf{GCN}}_{\mathbf{\text{linear}}}$ [23,29]: The adjacency matrix $\mathbf{A}$ is derived by treating the features in $F_{final}$ as nodes and applying the NOTEARS linear DAG structure learning algorithm [23] to construct the graph. This allows the GCN to leverage the causal structure inherent in the features, directly testing whether the graph structure learned by the linear causal model improves classification performance.
• ${\mathbf{GCN}}_{\mathbf{\text{nolinear}}}$ [28,29]: Similar to ${\mathrm{GCN}}_{\mathrm{linear}}$, the adjacency matrix $\mathbf{A}$ is derived from the Learning Sparse Nonparametric DAGs algorithm [28], which models nonlinear causal relationships between the features in $F_{final}$.

To make the distinction clear, we notate them as ${\mathrm{GCN}}_{\mathrm{euclid}}$, ${\mathrm{GCN}}_{\mathrm{linear}}$, and ${\mathrm{GCN}}_{\mathrm{nolinear}}$. The three GCN methods were also integrated as part of the comparison, and the integrated method was noted as ${\mathrm{GCN}}_{\mathrm{ensemble}}$. The experimental results are shown in

Table 4. Comparison of different methods based on $F_{final}$.

Method	Dataset 1			Dataset 2
	Accuracy (%)	F1 Score (%)	Time (ms)	Accuracy (%)	F1 Score (%)	Time (ms)
SVM	99.75	96.46	3.74	99.76	96.62	3.75
KNN	99.75	96.51	38.48 ± 0.50	99.76	96.75	37.94 ± 1.00
GCNeuclid	99.40 ± 0.10	91.52 ± 0.60	15.57 ± 1.20	99.49 ± 0.05	92.57 ± 0.30	15.50 ± 1.00
GCNlinear	99.51 ± 0.10	92.97 ± 0.60	12.82 ± 0.90	99.52 ± 0.05	93.26 ± 0.50	12.81 ± 0.90
GCNnonlinear	99.46 ± 0.10	92.07 ± 0.60	13.65 ± 1.20	99.49 ± 0.05	92.72 ± 0.10	13.66 ± 1.00
GCNensemble	99.53 ± 0.02	92.98 ± 0.30	43.02 ± 0.50	99.56 ± 0.05	93.60 ± 0.40	43.00 ± 0.50
WeDIGAR *	99.95 ± 0.01	99.35 ± 0.10	4.80 ± 1.00	99.95 ± 0.01	99.35 ± 0.10	4.80 ± 1.00

* Our proposed method.

.

As clearly demonstrated in Table 4, WeDIGAR achieves a superior accuracy and $F_1$ score compared to all other methods. While the SVM offers fast inference ($3.75\mathrm{ms}$ per sample), its $F_1$ score of approximately $96\%$ falls short of the stringent accuracy requirements (>$99\%$) essential for cloud service providers. On the other hand, GCN-based approaches (${\mathrm{GCN}}_{\mathrm{euclid}}$, ${\mathrm{GCN}}_{\mathrm{linear}}$, ${\mathrm{GCN}}_{\mathrm{nolinear}}$) suffer from prolonged inference times due to their model complexity and graph construction overhead, without delivering compensatory gains in detection performance. WeDIGAR effectively bridges this gap by combining a lightweight random forest classifier with high-quality features refined through causal selection, thereby achieving an optimal balance between precision and efficiency—this constitutes its core advantage for deployment in high-throughput edge computing nodes.

5.6. Compare with Our Previous Method

In this part, we compare WeDIGAR with the method used by Baishan Co., Ltd. and the historical version in the WeDIGAR research process. The comparison results are shown in

Table 5. Comparison with our previous method.

Method	Dataset 1			Dataset 2
	Accuracy (%)	F1 Score (%)	Time (ms)	Accuracy (%)	F1 Score (%)	Time (ms)
TF-IDF + RF	99.00 ± 0.05	86.84 ± 0.50	11.88 ± 0.05	99.00 ± 0.05	86.96 ± 0.50	11.86 ± 0.05
PC + RF *	99.76 ± 0.08	96.77 ± 0.80	8.26 ± 0.03	99.76 ± 0.08	96.77 ± 1.10	8.26 ± 0.03
WeDIGAR **	99.95 ± 0.01	99.35 ± 0.10	4.80 ± 1.00	99.95 ± 0.01	99.35 ± 0.10	4.80 ± 1.00

* “PC + RF” in the table means PC + RF with no $F_{sem}$; ** method proposed in this paper.

. It can be clearly seen that WeDIGAR has substantially improved its performance compared to the previous methods in terms of both accuracy, $F_1$ score, and prediction time.

We considered two approaches for our analysis. The first approach involves treating the HTML response body as plain text, without considering the implicit structural information granule. In this method, positive samples are extracted using the TF-IDF algorithm, and a random forest is utilized for discrimination. However, this approach overlooks the potential contained in negative samples.

The results in Table 5 clearly demonstrate three evolutionary stages of our methodology:

TF-IDF + RF: This approach treats the HTML response body as plain text, completely ignoring its semi-structured nature. Consequently, it fails to distinguish between identical keywords appearing in <script> tags versus <div> tags, resulting in significant feature noise. This represents the primary reason for its lowest $F_1$ score (∼86.9%).

PC + RF: This method introduces structural Information Granules (IGs) and causal filtering, achieving a significant performance leap ($F_1$ score∼96.8%). This proves that analyzing the HTML tag structure is crucial for distinguishing between normal and malicious responses. However, it entirely discards semantic information, unable to capture key textual features such as specific commands or function names commonly found in webshells.

WeDIGAR: Our final framework achieves a second performance leap by integrating both structural and semantic IGs. The NOTEARS algorithm acts as an “intelligent scheduler” here, causally selecting the optimal feature subset from the fused high-dimensional features that contains both important structural context and discriminative semantic content. This synergistic effect is the fundamental reason for why WeDIGAR achieves an $F_1$ score of 99.35% while simultaneously reducing the prediction time to 4.8 ms.

5.7. Parameter Sensitivity Analysis

A robust and practical model should not be overly dependent on a specific set of “magic” parameters. Therefore, we conducted a sensitivity analysis on the core hyperparameters of WeDIGAR to validate its stability under different configurations, which is crucial for its deployment in real industrial environments.

Given the stochastic nature of machine learning, we performed 10 independent experiments for each parameter setting and calculated the average and standard deviation of the $F_1$ score. This approach provides a more robust evaluation of parameter sensitivity than a direct comparison of accuracy and $F_1$ score alone, as it effectively mitigates the influence of randomness.

As shown in Figure 7, WeDIGAR maintains excellent $F_1$ scores (>99%) across a wide range of parameter values. Specifically, the following is determined:

• The performance shows minimal fluctuation when the number of subtrees varies between 10 and 50 (Figure 7a), indicating low sensitivity to this parameter and ease of tuning.
• Variations in the number of features (Figure 7b) and maximum depth (Figure 7c) have limited impact on performance, demonstrating that the feature set $F_{final}$ selected by NOTEARS is of high quality and that the model is resistant to overfitting.

This strong robustness to hyperparameters significantly reduces the deployment and maintenance threshold for WeDIGAR. Operators can achieve stable and superior performance without extensive parameter search, further demonstrating the practical value of our framework.

Furthermore, as parameters change, the prediction time may vary, which should be considered when selecting optimal parameters. The configuration chosen for our experiments is “number of subtrees: 20, number of features in subtrees: 10, maximum depth: none, positive–negative sample ratio: 25”.

5.8. Beta Testing

After validating the model in our lab, we proceeded to conduct beta testing. The accumulated time and average time taken to predict samples online within a timeframe of 800 s is depicted in Figure 8.

The second approach focuses solely on the structural information granule of the HTML response body. By matching the relevant features through regular expressions, we apply the PC algorithm to conduct causal analysis. Finally, a random forest is used for classification. This approach takes into account the structural information granule and incorporates causal analysis, which can potentially enhance the accuracy of the model.

WeDIGAR combines the strengths of the historical two methods. As a result, it achieves significant enhancements in terms of accuracy and $F_1$ score compared to other approaches. Additionally, WeDIGAR optimizes the prediction time, resulting in faster processing and improved efficiency.

Based on the observations made in Figure 8, we note that, for a dataset consisting of 100,000 samples, the average prediction time is approximately 5.5 ms. This differs from the results obtained during the experimental setup but aligns with our analysis of the time complexity of the WeDIGAR algorithm as discussed in Section 4.4.1. The prediction time of the algorithm is influenced by the length of the HTML response body text. Larger response bodies tend to result in slower processing times. However, as the number of samples increases, the average prediction time gradually stabilizes and fluctuates within a reasonable range (within 10 ms).

During beta testing, WeDIGAR processed a total of 360,000 data points. Among these, it accurately detected 44 instances of webshell attacks, among which 4 were checked out to be false-positive detections.

After experimental validation and beta testing on the superior accuracy and efficiency of WeDIGAR, it has been put into industrial operation. The actual running screenshot of WeDIGAR is shown in Figure 9.

6. Conclusions

This paper introduced WeDIGAR, a novel, lightweight webshell detection framework tailored for resource-constrained satellite and UAV edge nodes. Our approach extracts structural and semantic Information Granules (IGs), refines these features using a causal graph (NOTEARS) to eliminate spurious correlations, and employs a random forest for efficient classification. The crucial benefit of this methodology is its prediction efficiency: by selecting only causally relevant features, the model size is minimized, allowing for low inference latency (e.g., ⩽$10\mathrm{ms}$) necessary for real-time operation on single edge nodes. This lightweight nature validates the efficacy of WeDIGAR and enables its planned integration into large-scale network optimization frameworks. Future deployment across massive satellite and UAV networks will involve addressing multi-objective task scheduling using sophisticated tools, such as those leveraging bilevel evolutionary algorithms [30], to manage resources efficiently across thousands of multiagile nodes.

Despite its efficiency, WeDIGAR’s current limitation lies in its inability to detect webshells that use end-to-end encryption or those heavily reliant on custom obfuscation that completely transforms the standard HTTP response body content. Because the model relies on structural and semantic patterns within the cleartext HTTP response, its effectiveness is compromised when these patterns are fully masked. Addressing this critical security boundary—specifically developing methods robust to encrypted files and advanced obfuscation techniques—will be the primary focus of our future algorithmic work.